View previous topic :: View next topic |
Author |
Message |
SirAlaran
Joined: 19 Feb 2007 Posts: 84 Location: Silicon Valley
|
Posted: Mon Feb 19, 2007 12:54 pm Post subject: Runtime Error: SDL_ClearError() |
|
|
Hello. I'm having some trouble running anything built with Derelict. I always get a segmentation fault in the call to SDL_Init. gdb backtrace is as follows:
Code: |
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4157143232 (LWP 15919)]
0x080845c8 in SDL_ClearError ()
(gdb) bt
#0 0x080845c8 in SDL_ClearError ()
#1 0xf7eb9e7f in SDL_Init () from /usr/lib32/libSDL-1.2.so.0
#2 0x0804e191 in _Dmain (argvs=579015020893962241) at main.d:8
#3 0x00000001 in ?? ()
#4 0xffc6b108 in ?? ()
#5 0x08058323 in main ()
|
Code: |
import derelict.sdl.sdl;
void main(char[][] argvs)
{
DerelictSDL.load();
SDL_Init(0);
SDL_Quit();
DerelictSDL.unload();
}
|
Compiled as follows:
Code: | dmd main.d -I/home/alaran/src/D/dmd/src/ext -c -g && gcc *.o -o main -lphobos -m32 `sdl-config --libs` |
I'm running 64-bit Gentoo Linux on my main computer. I run the linker myself so that it will link against the 32-bit SDL instead of the 64-bit, however compiling and linking normally on my 32-bit Ubuntu system has the same problem.
DMD is 1.006, GCC is 4.1.1, SDL is 2.1.11(Gentoo) 2.1.10 (Ubuntu) Derelict is trunk-r228
Any ideas? |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Mon Feb 19, 2007 7:17 pm Post subject: Re: Runtime Error: SDL_ClearError() |
|
|
SirAlaran wrote: | I'm running 64-bit Gentoo Linux on my main computer. I run the linker myself so that it will link against the 32-bit SDL instead of the 64-bit, however compiling and linking normally on my 32-bit Ubuntu system has the same problem. |
The segfault is happening on the C side. DerelictSDL appears to be loading successfully since you can call SDL_Init just fine. I would wager a hefty sum that your problem arises from linking SDL on the command line. That is something you neither should nor need to do. Derelict loads the SDL shared library manually when you call DerelictSDL.load. It does this through libdl. So add -ldl to your command line and remove the SDL stuff.
Once that is done, you may need to pass in a specific library name to DerelictSDL.load in order to specifically load the 32-bit version. It depends upon how the versions are named on your system. Look at derelict.sdl.sdl.d to see which library names are searched for by default.
On a side note, the call to DerelictSDL.unload is extraneous. It will be called automatically in a static module destructor. It doesn't hurt anything, but you don't need it unless you explicitly want to control when the shared library resources are released. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
SirAlaran
Joined: 19 Feb 2007 Posts: 84 Location: Silicon Valley
|
Posted: Mon Feb 19, 2007 7:38 pm Post subject: |
|
|
It all seems so simple now!
Code: |
import derelict.sdl.sdl;
void main(char[][] argvs)
{
DerelictSDL.load("/usr/lib32/libSDL-1.2.so.0");
SDL_Init(0);
SDL_Quit();
}
|
The build command I used on my 32-bit system was pretty much the same as what I used on the 64-bit. You were right, linking it myself doesn't work. I have lots of experience with C, C++, and some Java, but I'm still fairly new at D.
Thanks for your help. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Mon Feb 19, 2007 11:19 pm Post subject: |
|
|
SirAlaran wrote: | You were right, linking it myself doesn't work. I have lots of experience with C, C++, and some Java, but I'm still fairly new at D. |
Well, this isn't actually a 'D-thing'. It's a 'Derelict-thing'. Most D bindings do require you to link to the library yourself. Derelict was intentionally designed to avoid that. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
Deltafire
Joined: 21 Feb 2007 Posts: 4
|
Posted: Sat Feb 24, 2007 5:32 pm Post subject: |
|
|
I'm getting the exact same error when using gdc to compile (using the previous test program):
Code: |
$ rebuild test.d -lldl -v
...
compile gdmd -version=Posix -version=Tango -c test.d derelict/sdl/sdl.d derelict/util/loader.d derelict/util/exception.d derelict/util/wrapper.d derelict/sdl/active.d derelict/sdl/types.d derelict/sdl/audio.d derelict/sdl/rwops.d derelict/sdl/byteorder.d derelict/sdl/cdrom.d derelict/sdl/cpuinfo.d derelict/sdl/endian.d /usr/local/bin/../include/d/4.0.3/std/intrinsic.d derelict/sdl/error.d derelict/sdl/events.d derelict/sdl/keyboard.d derelict/sdl/keysym.d derelict/sdl/mouse.d derelict/sdl/video.d derelict/sdl/mutex.d derelict/sdl/joystick.d derelict/sdl/syswm.d derelict/sdl/sdlversion.d derelict/sdl/loadso.d derelict/sdl/thread.d derelict/sdl/timer.d -I/usr/local/include/d/ -od.
link gdmd ./test.o ./derelict.sdl.sdl.o ./derelict.util.loader.o ./derelict.util.exception.o ./derelict.util.wrapper.o ./derelict.sdl.active.o ./derelict.sdl.types.o ./derelict.sdl.audio.o ./derelict.sdl.rwops.o ./derelict.sdl.byteorder.o ./derelict.sdl.cdrom.o ./derelict.sdl.cpuinfo.o ./derelict.sdl.endian.o ./std.intrinsic.o ./derelict.sdl.error.o ./derelict.sdl.events.o ./derelict.sdl.keyboard.o ./derelict.sdl.keysym.o ./derelict.sdl.mouse.o ./derelict.sdl.video.o ./derelict.sdl.mutex.o ./derelict.sdl.joystick.o ./derelict.sdl.syswm.o ./derelict.sdl.sdlversion.o ./derelict.sdl.loadso.o ./derelict.sdl.thread.o ./derelict.sdl.timer.o -oftest -q,-rdynamic -L-lSDG-tango-stdc -L-lSDG-tango-stdc -L-lSDG-tango-sys-linux -L-lSDG-tango-sys-linux -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc -L-lSDG-tango-stdc-posix -L-lSDG-tango-stdc -L-lSDG-tango-stdc -L-lSDG-tango-stdc -L-lSDG-tango-text -L-lSDG-tango-stdc -L-lSDG-tango-stdc -L-ldl
|
Note that this is using Tango, I have also tested using Phobos (on a different computer) and get the same error. DMD appears to work fine. |
|
Back to top |
|
|
Deltafire
Joined: 21 Feb 2007 Posts: 4
|
Posted: Sat Feb 24, 2007 5:58 pm Post subject: |
|
|
Found the problem - it was caused by the -rdynamic flag that was being passed to the linker. I've now removed the flag from rebuild's configuration files. |
|
Back to top |
|
|
volcore
Joined: 22 Jan 2007 Posts: 19
|
Posted: Sun Feb 25, 2007 5:26 am Post subject: |
|
|
I had the same error, in my case it was caused by statically linking libSDL. |
|
Back to top |
|
|
SirAlaran
Joined: 19 Feb 2007 Posts: 84 Location: Silicon Valley
|
Posted: Tue Feb 19, 2008 6:16 pm Post subject: |
|
|
Deltafire wrote: | Found the problem - it was caused by the -rdynamic flag that was being passed to the linker. I've now removed the flag from rebuild's configuration files. |
BE SURE TO GET RID OF -rdynamic IN REBUILD'S CONFIG FILE.
I already tore my hair out because of this. Trust me. |
|
Back to top |
|
|
|