Opening CLIB4 Shared Objects and clib4.library

[3246251196]

Shared Objects

We should agree on some sort of standard for opening CLIB4 SOs. Right now, our dynamic loader will look in the PWD or the PWD/sobjs directory in preference to SOBJS:. That would mean that we would have to distribute all programs built with CLIB4 with the SOs in either PWD or PWD/sobjs.

I am assuming that it would be a bad idea to put any CLIB4 SOs into SOBJS: since that location should be kept for NEWLIB.

We could modify elf.library to check in SOBJS:clib4, but we would need to get elf.library to do that only when it knows that the binary was built with CLIB4.

We could implement RPATH in elf.library. That would mean that we would need to remember to apply that mechanism when linking the program. Or, we could implicitly do this always via changing ADTOOLS.

Any more options or ideas - other than the obvious and - my personal favourite - of linking statically, always!

clib4.library

Whether linking statically or dynamically, this is relevant. Unlike NEWLIB, CLIB4 is changing rapidly in relative terms. Either clib4.library is already resident, or it exists in LIBS:. We could force a transient modification to LIBS: to add the PWD to LIBS so that OpenLibrary would also check PWD in the case that a particular clib4.library is distributed.

[walkero-gr]

About so and the library files, I was under the impression that the system always checks first the PWD and then the sys: drive. Isn't that the case?

Also, what happens when an app loads clib4.library from libs: and then another app loads it from its folder? I believe that since it is in memory, the second app will use this one and will not load it again, unless there is a restriction on the version.

[smarkusg]

• library are always loaded first from ‘SYS’.
  *so checks first PWD:LIbS ... PWD then SYS

[3246251196]

Hey, @walkero-gr.

Right, for SOs then it will look into the binary's location first. So, this is fine. If we are happy to do that, then fine.

As for shared libraries - that is a different story. If it is not in memory already, it will check LIBS: unless you hack that assign to include an additional location, which is what I used to do for adtools_testing. (EDIT: Not true since CLIB4 uses RomTags. There are a bunch of other paths it checks, starting with: Memory resident, if not, LIBS:, if not ...etc... if not, PWD:, if not PWD:Libs...)

This is just about a standard approach. If we are happy to just distribute SOs with the program, then fine; but you better not forget to put it there, otherwise a small nuclear explosion may occur with a mess of the loader using NEWLIB SOs from SOBJS:

[smarkusg]

Current dynamic libraries (.so) are better to use static libraries in clib4 to avoid, as rjd324 wrote, the problem of loading libraries from NEWLIB

[afxgroup]

I don't think we can do a lot if Ramlib/Elf cannot be patched/changed. At moment clib4 .so and .library works like any other OS4 component. I don't know how you can change the behaviour without touching the OS

[3246251196]

Exactly. So, would you be happy to always distribute SOs along with zip'd program, or should we definitely change our dynamic loader?

[3246251196]

This is why I could not find the discussion, because it was on CLIB4. Fine. Anyway, we have made the decision to go ahead with infixing name/versions into the SO files. I will close this with this comment, but feel free to re-open if needed.

[migthymax]

All those wondering where the discussion took place