Steve Morris wrote:
> I think a lot of my problems are trying to apply logical conventions
> based on mainframe operating systems, and not being able to understand
> why there are convoluted processes in place when there are simpler and
> more logical ones available (this libglx cyclic nature with xorg is a
> case in point).
>
I assume you mean z/OS, but you'll have similar issues there, just
different terminology: "Search order", and TASKLIB overrides STEPLIB
overrides JOBLIB overrides (E)LPA.

An issue closer to this example is the way Language Environment resolves
external symbols between DLLs. If you link statically, everything can
be resolved at link time. If you link dynamically, the loader replaces
the various external VCONs with magic odd addresses which cause a
program check when used; the program check handler then resolves them
when the address is used.

I think Linux falls between the two, in that dynamic linking requires
you to supply the linker with the generic name of the library to search,
and at load time the loader scans the ldconfig path for libraries whose
explicit names "provide" the generic name, e.g. libc.so.1 provides libc,
so that it can resolve the reference.

Just as a point of history, OS/2 provided all three possibilities:
static, resolve-at-load, and resolve-at-first-use.