Dynamic linker problem?

I'm having problems when linking with a shared objects which has references to another shared object. It seems to be important to resolve all those library dependencies at link-time, otherwise the executable crashes.

As an example I want to link with SDL_mixer.so:

This works:
-lSDL -lSDL_mixer -lFLAC -lsmeg-0.4 -logg -lvorbisfile -lvorbis -lmikmod -lpthread -lstdc++ -lgcc

But this does not (although all references of my executables have been resolved):
-lSDL -lSDL_mixer

I think it's a problem of the dynamic linker, which has to resolve all dependencies to other shared objects automatically. Is it a known problem and there was a directive to use the workaround from above?
Will it be fixed?

@phx
If you have symbols at runtime which are unresolved, elf.library currently crashes your app by writing to zero. The next elf.library will pop up a requester to tell you and suspends your process instead. In any case, your app is broken.

@ssolie
Ok, so it's a known problem which one should be aware of.

Although I would tend to regard that as a bug of the dynamic-linker in elf.library. Any other operating system using ELF shared objects can deal with it. Usually you only have to resolve the references at link-time which come from your program, not from shared objects.

Are there plans to fix that?

I contacted Hans-J?rg Frieden privately and he said that recursive symbol resolving with shared objects should work, provided the elf.library is new enough (which version? I have 52.4) and that the shared objects have a V2 tag. I.e. "objdump -p" must show the tag:
0x6000000e 0x2

But even with the latest SDK the problem remains. All gcc shared objects do not have the V2 tag: libgcc.so, libstdc++.so, libssp.so. So, as far as I understood, the dynamic linker still requires you to specify all libraries on the linker command line... :(

@phx

OS4.1 Update1 includes elf.library 53.10.

@ZeroG

But does it solve the above mentioned problem?

And I'm not a registered user. Maybe I will be, when the X1000 is available. But for the moment I have to live with my outdated beta version.

@phx
Quote:
I don't know, but i could test it for you...
Quote:
Why?
The updates are free and it does not make much sense to develop for betaversions (or "final"version that can be updated -for free- (OS4.1 for A1 und peg2) of OS4.1 that nobody should run anymore. If you want to support OS4.0 it's best to use static linking, dynamic linking is very buggy in 4.0.

@ZeroG

Maybe a bit offtopic, but still, about dynamic and static linking. So, what i noticed in last time: if for example i do on linking stage -lphtread, and, i have in the my LIB directory : libpthread.a libbpthread.la and libphtread.so => then, it compile binary dynamicaly (and try to found on running, in sobjs: libpthread.so). If i remove from my stub LIB directory .so file, and then, there is only .a and .la, then, it compliles statically.

And that is strange for me, because i think before, if i not use -use-dynld at all on linking stage, then, everythinkg will be 100% compiles statically, and if i will use -use-dynld , then, only in that case it will be compiles dinamycali. But looks like not ? That is bug, or misunderstoonds from my side, or what ?

Its not problem for me to not have any .so inside of LIB , but still, why ?

@kas1e

I'm the wrong person for that question, i am only a user that sometimes tries to code something. You should ask that a coredeveloper and / or someone from the SDK team.

@kas1e
Although I have got some other problems, but this works for me.

At least the gcc from the current SDK which I tested will only link shared objects with -use-dynld (and annoyingly also requires to resolve even all inter-dll references during linking).

@ZeroG

If you would like to test, which I much appreciate, you can download a tiny shared object test from: http://sun.hasenbraten.de/~frank/TEST/sotest.lha

The main program test will call alpha() from libalpha.so, which will call beta() from libbeta.so. test only requests libalpha and relies on elf.library to recursively resolve the reference to libbeta.

I terminated my OS4 developer account last year, so I would have to buy a legal 4.1 version to be registered (but I never cared how this process worked)? I guess I will better wait for the X1000 before doing so...

@phx

I get a requester from elf.library saying "Unable to resolve symbol 'beta'".

The requester has only one button labeled "Okay" and if i click it it summons the grimreaper (DSI error).

Do you (or somebody else) need the crashlog?

@ZeroG
Quote:
Yes it is. Only use AmigaOS 4.1 Update 1 and higher for shared object projects. Otherwise you will end up wasting a lot of time chasing ghosts that were fixed in Update 1.

@all
There is some info. on the V1 versus V2 problem in the SDK as well which was added starting with SDK 53.20. See "AmigaOS 4.1 SDK.pdf", Section 5 Shared Objects. This document tries to consolidate all the current info. on Amiga shared objects. If there is anything wrong/missing/etc. please email me directly so it can be fixed.

@ssolie

Do not know it is bug or not, but if i not use -use-dynld (but have in the LIB directory just sobj of the lib which i link) on the compiling stage, i still have automate compilation of dynamic binary. It must be like this ? (as i think it must be not).

Its like i do: gcc test.c -o test -lgcc++
and if, in my sdl LIB directory i have gcc++.so, then, it test.c compiles automatically as dynamic, with .so support, and try to found on the running stage need it .so , in the sobj: directory,

But as i understand, that must be happenes only if i add -use-dynld, and not because i have that sobj in LIB directory .. (imho)

@ZeroG
Quote:
That's a pity. After reading Hans-J?rg's mail I had some hope that it will work with recent versions. :|
Thanks for your test. So I need some workaround for it.

Quote:
No. I know that the crash happens in an uninitialized PLT slot from libalpha to beta().

@phx

elf.library 53.12 (OS4.1 Update2) is still unable to resolve symbol 'beta'. But it does not crash anymore, it now gets suspended.

@kas1e

If your linker line includes "-use-dynld" or "-shared", then dynamic .so libraries are preferred over static .a. Otherwise, it uses static libraries (.a).

That's assuming you are using gcc.

@phx

With Update 2 now out, I might get some time tomorrow to check out your problem. Sorry that I didn't get the time earlier, it would have been preferable to get this fixed in Update 2 (if it is a problem with elf.library) but there wasn't any more time.

Edit: update 2, not update 1 :$