Hyperion Entertainment Message Boards

http://capehill.kapsi.fi/sdl2/sdl2_pthr ... _crash.txt here is a crash log when trying to start and older SDL2 application with new SDL2 shared object that is explicitly linked with pthreads. DSI is ignorable in a sense that application seems to work normally. I can see an assert (from the kernel?) in the serial log. Is it possible to say what is the issue?

I don't think you can't change the linking of a shared object and not relink the executable using it.

Is there any reference for the relinking rule?

Meanwhile, it looks like my problem is solved and there is no crash anymore. I'm not 100% sure about the rootcause but I suspect a faulty cmake configuration or a dirty build. It looks like produced shared object is compatible after all, which is great.

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.

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?

This is what I did way back when creating the perlSDL port on the old version of my perl port (5.8 was clib2 based). Given that you are already loading your plugin "dynamically" via loadseg, the extra layer of complexity seems redundant. You might need an SDL build for clib2 for that but your problems would all disappear....

The best solution of all IMHO would be for someone to create a sdl2.library , it shouldn't be that hard as SDL is not C++ based (unless it changed since I last looked which is ages ago ....)

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.

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.

Well ask them too then!

SDL1 was had both clib2 and newlib versions ad it was no maintenence hassle at all.

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.

Why would you thnk that? I can tell you now, you defeinetly don't. It should just require a couple of tweaks on the SDL 2 makefile and the odd conditional include in the src.

If you linking a library (or plugin) with no startfiles, you might need to call the constructors , but I belive there is a skeleton code for that in the clib2 src archive. __lib_init() and __lib_exit() are the relavent clib2 functions that do that for you IIRC.

But then again if your plugin is self contained and you never exchange any file handles etc you could easily link against the newlib static version .

Still, there is some sort of academic curiosity on my side as to whether the original plan is possible. You have somehow hijacked the thread now by providing alternative solutions which is ok but I'd still like to know whether the original plan is possible, so please someone take a look at this post again.

Sorry wasn't my intention to hijack the thread, rather to help provide solutions to the ultimate goal of a working plugin

returning to the imediate problem

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

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.

3) This Hollywood plugin is then LoadSeg()'ed by Hollywood itself but Hollywood uses clib2-ts and isn't linked against -lpthread

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.

broadblues wrote: The plugin itself is compiled withy newib? Given that -nostartfiles is inuse I presume you have explicitly added -lc ?

Yes. And I open newlib.library in the plugin. This is working. I can call printf() and the output is presented in a window opened by newlib.

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.

Don't understand what you're trying to say here, please explain

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.

No, that's not the case. Of course there will be no contact between the plugin's clib (= newlib) and Hollywood's clib (= clib2).

Still it is crashing when doing DLOpen() on libSDL2.so. The same code works when using a little test program. It only crashes when DLOpen() is called from my plugin.