softwarefailure wrote:With this fix I can now manually load libSDL2.so from a little test program and call SDL_Init() and SDL_Quit() just fine.
However, I cannot do this from a plugin which is compiled with -nostartfiles and then loaded by Hollywood via LoadSeg(). I think the problem could be that Hollywood itself uses clib2-ts instead of newlib and Hollywood doesn't link against -lpthread either because it doesn't use pthreads and AFAIK pthreads aren't available for clib2 anyway. Hollywood also doesn't use -use-dynld.
So is it possible to use libSDL2.so from a plugin that is opened by a clib2 program at all?
Here is a little overview:
1) libSDL2.so uses newlib and pthreads
2) The Hollywood plugin which manually opens libSDL2.so and newlib.library is compiled with -use-dynld and then linked with -lpthread and -nostartfiles
3) This Hollywood plugin is then LoadSeg()'ed by Hollywood itself but Hollywood uses clib2-ts and isn't linked against -lpthread
Is this possible? Currently it crashes on DLOpen() for libSDL2.so.
Excuse the dumb question, but why don't you just statically link your plugin against the static version of SDL?
Excuse the dumb question, but why don't you just statically link your plugin against the static version of SDL?
Because the SDL2 maintainers don't provide a clib2-compatible static link library of SDL2.
On top of that, making SDL2 clib2 compatible is probably a lot of work because you'd have to go through the code and replace all calls to constructor/destructor-dependent functions like fopen(), sprintf(), etc. with custom versions. And of course you'd have to do it all again for every update of SDL2. Not really an appealing solution.
1) libSDL2.so uses newlib and pthreads
2) The Hollywood plugin which manually opens libSDL2.so and newlib.library is compiled with -use-dynld and then linked with -lpthread and -nostartfiles
3) This Hollywood plugin is then LoadSeg()'ed by Hollywood itself but Hollywood uses clib2-ts and isn't linked against -lpthread
broadblues wrote:The plugin itself is compiled withy newib? Given that -nostartfiles is inuse I presume you have explicitly added -lc ?
If the constructors in the shared library are called by DLOpen() and those construtors reference a libc function that would possibly cause a crash if omitted.
I don't think that parent program needs to use the same (or any) c library as the plugin, since you aren't using dynamic linking to load the plugin itself. However, if any part of the plugin API accepts file handles, sockets or similar as arguments difereing c libraries *would* then be an issue.
Return to General Developer Support
Users browsing this forum: No registered users and 1 guest