Segmentation fault after second dlopen() attempt
My name's Patrick, and I'm a mod developer for a game named Jedi Knight 2: Jedi Outcast.
The game is quite old (2002!) and I'm trying to mod the old version of it (1.02a), the jk2ded server linux binary.
The game engine loads my mod's .so file which I compiled using:
When a map changes on the server, the .so file has to be unloaded.
After unloading with dlclose() without errors, when the new map is launched the engine tries to reload the .so into the memory with dlopen() but fails:
So I used gdb to find out why it does that, but all I got is:
Can you make it unload/reload without changing maps? If so, try it out. That should tell you if it's a problem with the map change. Does the mod get uploaded to another machine, i.e. does it run from a different machine than the one it's compiled on? If not, try dropping -static, also.
PS Do nm out/jk2mpgamei386.so | grep ' U '. If you see anything, that's a problem (in this particular case; it's normal otherwise.)
Thanks for the reply. I'm not able to unload the .so without map change. I am compiling the jk2mpgamei386.so in Cygwin under Windows 7 and I run it at a different machine (Linux server - Debian Etch 2.6.24).
I did the command.
Here are the results:
I noticed one of the undefined symbols (strlen) matches frame from the gdb backtrace.
Thank you for the reply again,
kind regards :-)
I removed all references to strlen and the rest of the undefined symbols from my code so that the nm command I used doesn't print anything anymore.
Now it crashes with a reference to __deregister_frame_info_bases which is in libc.so.6.
I think I should link the libc with my .so statically. How can I achieve this?
I have the libc.a file that I want to link to my .so file but I don't know how to launch gcc so it compiles with libc statically.
Can you help me out?
I managed to solve my problem.
I used this command to compile statically linked jk2mpgamei386.so:
|All times are GMT -5. The time now is 12:35 AM.|