| View previous topic :: View next topic |
| Author |
Message |
gfannes
Joined: 06 Oct 2009
Posts: 7
Location: Zoersel, Belgium
|
 Posted: Tue Dec 14, 2010 1:21 pm Post subject: |
 |
|
Mmh, sorry for the "if (false)", that's indeed quit confusing...
Here is a more polished test program and a Ruby script that I used to compile it. Maybe other people running linux can test this too, just download both files to one folder, adjust the first line of build.rb to point to your Derelict2 dir and run "ruby build.rb". This results in 5 different executables (Manual, DerelictUtil, DerelictSDL, DerelictUtilLib and DerelictSDLLib).
The test program contains 3 different ways of loading SDL: manually using dl, using DerelictUtil, and using DerelictSDL. The last two methods are tested twice, once for an executable built immediately from source files (also the relevant Derelict2 files), and once linking against the Derelict2 lib.
Only DerelictSDL and DerelictSDLLib segfault for me, the rest is fine.
I'm currently running dmd v2.049 running on Arch linux for which "uname -a" gives: "Linux ri 2.6.35-ARCH #1 SMP PREEMPT Sat Oct 30 19:57:05 UTC 2010 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux".
I'll test it for dmd v2.050 and on a Linux Mint box and post the results.
Greetings,
Geert. |
|
| Back to top |
|
 |
marcode
Joined: 08 Jan 2011
Posts: 3
|
| Posted: Sun Jan 09, 2011 11:34 am Post subject: |
|
|
Maybe this is originated by a compiler bug?
I have the same problem with DerelictSDL. I also have problems with DerelictSDLImage and DerelictFT.
To test the loading of DerelictFT, I wrote the following program:
| Code: |
extern (C)
{
void *dlopen(const char *, int);
void *dlsym(void *, const char *);
}
alias int FT_Error;
struct FT_LibraryRec_;
alias FT_LibraryRec_* FT_Library;
void main()
{
FT_Library ftlibrary;
void* h = dlopen("libfreetype.so.6", 2 );
auto init = cast(FT_Error function(FT_Library*)) dlsym(h, "FT_Init_FreeType");
init( &ftlibrary );
}
|
which crashes if i compile it without optimization in dmd 2.051. However, if i use the -O switch it doesn't crash anymore. |
|
| Back to top |
|
|
tbone
Joined: 05 Nov 2009
Posts: 19
|
| Posted: Mon Jan 10, 2011 1:27 pm Post subject: |
|
|
| Try *NOT* linking with --export-dynamic or -rdynamic |
|
| Back to top |
|
|
marcode
Joined: 08 Jan 2011
Posts: 3
|
| Posted: Mon Jan 10, 2011 3:22 pm Post subject: |
|
|
The same thing happens without them:
dmd testderelict.d -c
gcc testderelict.o -o testderelict -m32 -ldl -lphobos2 -lpthread
./testderelict
(segfault) |
|
| Back to top |
|
|
tbone
Joined: 05 Nov 2009
Posts: 19
|
| Posted: Mon Jan 10, 2011 3:35 pm Post subject: |
|
|
| Might be something in dmd then, because it is working fine for me with gdc |
|
| Back to top |
|
|
marcode
Joined: 08 Jan 2011
Posts: 3
|
| Posted: Tue Jan 11, 2011 2:32 pm Post subject: |
|
|
| Yes. gdc works for me too. |
|
| Back to top |
|
|
tbone
Joined: 05 Nov 2009
Posts: 19
|
| Posted: Tue Jan 11, 2011 3:18 pm Post subject: |
|
|
Now the same issue is popping up for me with certain compiler optimizations turned on.
Its the same issue, SFML trying to call the glXGetConfig() defined in my binary rather than the one that it's suppose to be linked to (maybe some link-time optimizations do this?)
Edit: Found it!
This time it was -fPIC causing the issue, which really is only needed for shared libraries anyway.
It's all because of the way Derelict does its runtime loading of libraries, it breaks many things with the compiler and linker because it defines the library symbols differently (as pointers to the symbols, and not as symbols themselves). |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
