Frank Griffin wrote:
> 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.
>
z/OS and OS/2 are/were significantly easier to understand.

regards,
Steve