CLIB4 Shared Objects and Shared Library

If anyone is interested in declaring a technical preference for CLIB4 distributed programs, you may want to contribute to https://github.com/AmigaLabs/clib4/discussions/212.

@rjd324
Thank you for setting up this topic.

@rjd324

Yeh, should be different directories for clib and newlib .so files.
nothing to debate, it will conflicting other vice.

I guess the elf.library, need to check for const symbol in ELF file. like we do with version strings.

With that fix done, and the memory leek done, it should be ready to be used, for real.

ramlib and how that works is a different topic. We don’t need to debate.

@rjd324
A separate directory like SOBJS:clib4/ isn't required, nor any changes in the compiler/linker (ld) and the loader (elf.library), just make sure any .so using clib4 has "clib4" in it's soname, for example use -soname libSDL_gfx_clib4.so.23 instead of -soname libSDL_gfx.so.23 (newlib) when building libSDL_gfx.so.
Although most developers ignored it, and created a linux/windows like .so/.dll hell instead, there never must be any soft links in SOBJS:

Instead it should be done the following way:
- In the SDK (newlib/lib, clib/lib, etc.) directory you have a libFOOBAR.so, which may be a soft link to the current version, build for example with -soname libFOOBAR.1.2.3.so (newlib) or -soname libFOOBAR.1.2.3_clib4.so (clib4) for version 1.2.3.
- In SOBJS: (and PROGDIR, PROGDIR:sobs) there never is any libFOOBAR.so, and especially no libFOOBAR.so soft link to a specific version, but just the regular files libFOOBAR.1.2.3.so and libFOOBAR.1.2.3_clib4.so.

GCC/ld uses the (current) libFOOBAR.so version from the SDK:(newlib|clib4|ixemul|whatever)/lib directory when linking the executable. It never must use anything from SOBJS: instead for linking!
The loader/elf.library doesn't use (SOBJS:|PROGDIR:|PROGDIR:Sobjs/)libFOOBAR.so when loading an executable linked with it, but uses the soname from it instead (libFOOBAR.1.2.3.so, libFOOBAR.1.2.3_clib4.so, libFOOBAR.1.2.3_ixemul.so, ...).

If it would be done correctly, as proposed and used by the OS4 development team about 20 years ago, there never would be any problems with different .so versions (different versions of the library, using different C libraries, etc.) of the same library as all of them in SOBJS: (and PROGDIR:, PROGDIR:Sobjs/) have a different file and soname.

what is the difference between clib2 and clib4?

@joerg

Your suggesting was added it to back of name, but you add it to front of name perhaps.
clib4_libsdl_x.x.x.x.so

this why list of files will be sorted.

I think troublesome, considering that most stuff, is ported from other OS’s,
you need modify the build process to add the “clib4” part to the name.

__attribute__((__used__)) const char *os4_c_library = “clib4”;
can be put into the link library and forgotten.

@LiveForIt
It doesn't make any difference if you put "clib4", "newlib", etc. at the front or back of the (so)name, it just has to be a different one for each C library.

I never tested if that works with GCC/ld and elf.library, but if it does using "clib4/" as first part of the -soname for clib4 versions of shared objects you could even have all clib4 .so files in a separate directory (SOBJS:clib4, PROGDIR:clib4, PROGDIR:sobjs/clib4).

Quote:When porting software from other OSes to AmigaOS next to nothing works without any modifications in the Makefile(.am|.in), CMakeFile, etc., anyway, adding a "clib4" part in the soname of shared objects is one of the easiest changes you have to do.

Quote:Would require updated ld and elf.library to make it work.
May be easier, if you don't care that such changes can take several years to be implemented, if it happens at all...
Using different sonames for each C library instead works since about 20 years, and doesn't need any changes in adtools nor elf.library.