However, it does not work. Calling m_SDL_Init() results in the following error message from ELF Library: "Unable to resolve symbol: pthread_key_create". And after that: "Failed to resolve symbol at runtime. Process ... has been suspended".

Why does this not work and how can I fix it?

The ultimate goal is to be able to use libSDL2.so from a project that is linked without compiler constructor/destructor code, i.e. with the -nostartfiles option. The code above is just a test. The code above has been compiled using:

However, it does not work. Calling m_SDL_Init() results in the following error message from ELF Library: "Unable to resolve symbol: pthread_key_create". And after that: "Failed to resolve symbol at runtime. Process ... has been suspended".

Why does this not work and how can I fix it?

The ultimate goal is to be able to use libSDL2.so from a project that is linked without compiler constructor/destructor code, i.e. with the -nostartfiles option. The code above is just a test. The code above has been compiled using:

Your application needs to be dynamically linked at the very least. Manual low level elf.library calls are not going to be easy to use maybe try libdl? Perl uses libdl to load it's modules (as probably does python) if your surnames not Frieden you probably don;t want to mess with elf.library directly

I've tried to use dlopen(), dlsym() and dlclose() directly but it doesn't work at linker stage. The linker complains about being unable to resolve the dlopen(), dlsym() and dlclose() symbols which isn't surprising because there doesn't seem to be any linker library in the newlib SDK target that has those symbols. clib2 seems to have them but not newlib.

See what just changing to this does....gcc -D__USE_INLINE__ -use-dynld test.c -lauto -lpthread

When using this the error message goes away, but instead the program instantly crashes when calling m_SDL_Init(), so it doesn't work either.

if your surnames not Frieden you probably don;t want to mess with elf.library directly

Well, I'll do whatever it takes to get this working. Manually opening the shared object and importing the symbols seemed to be the most straightforward way but apparently there is so more magic to it, so please someone advise what I can do to get this working.

I've tried to use dlopen(), dlsym() and dlclose() directly but it doesn't work at linker stage. The linker complains about being unable to resolve the dlopen(), dlsym() and dlclose() symbols which isn't surprising because there doesn't seem to be any linker library in the newlib SDK target that has those symbols. clib2 seems to have them but not newlib.

There is no libdl.a just a libdl.so You have to use dynamic linking. there should be alink in your SDK to the copy in SOBJS:

See what just changing to this does....gcc -D__USE_INLINE__ -use-dynld test.c -lauto -lpthread

When using this the error message goes away, but instead the program instantly crashes when calling m_SDL_Init(), so it doesn't work either.

Perhaps the shared objects constructors need calling?

Most of them have symbols like

__shlib_call_constructors etc

don't know what the prototype for that would be.

I'm thinking that using libdl will call the constructors for you, but using elf.library direct you would need to call them youself, which involves knowing how to call them properly (or guessing I suppose).

My much earlier perl port used elf library calls IIRC but the modules weren't true shared objects, just custom binaries, when I switched to newlib I started using proper shared objects for the modules and switched to newlibs libdl.so (in part because there was existing perl code to easily adapt to the job).

So I think what we need to find out is how the second version actually initializes libSDL2.so and then imitate this behaviour in the first code... has really nobody ever tried this before? I don't think it is such an exotic thing to do to try to manually open a shared object instead of having the compiler constructor do this...

I haven't yet figured out how to pass -lpthread to libtool (for configure/make build) but I'm able to build the r178 using cmake (+gmake), and that produces a shared object linked with pthreads.

But unfortunately it is not compatible with the old binaries that were linked with older libSDL2.so and this is bad. Crash is somewhere in pthread/kernel. So I'm wondering is this caused when both the .so and the binary are dynamically linked with pthreads or is there something else.. I will post a stack trace later when I get back to my Amiga system. EDIT: this issue seems to be solved now and can be ignored.

Last edited by capehill on Fri Jun 30, 2017 5:44 pm, edited 1 time in total.