| View previous topic :: View next topic |
| Author |
Message |
JNewt
Joined: 05 Jun 2008
Posts: 69
|
 Posted: Wed Oct 06, 2010 3:00 pm Post subject: Derelict SFML bindings compatible with 1.6? |
 |
|
I've been using the Ubuntu Meerkat beta and all of my Derelict/SFML based apps have been crashing with segfaults in various glXQuery functions. I've been assuming that this was a driver or Xorg issue, but I recently discovered that my libcsfml is now at 1.6. I seem to recall that Derelict's bindings worked with 1.5; did 1.6 break binary compatibility or something?
Using latest revision (153) of the derelict 2 branch. |
|
| Back to top |
|
 |
JNewt
Joined: 05 Jun 2008
Posts: 69
|
| Posted: Mon Oct 18, 2010 1:45 pm Post subject: |
|
|
Still haven't found any solution to this. Here's a full backtrace:
| Code: | Program received signal SIGSEGV, Segmentation fault.
0x08180bb8 in glXGetConfig ()
(gdb) bt
#0 0x08180bb8 in glXGetConfig ()
#1 0xb6227b47 in sf::priv::WindowImplX11::CreateContext(sf::VideoMode const&, XVisualInfo&, sf::WindowSettings&, XVisualInfo, unsigned long) ()
from /usr/lib/libsfml-window.so.1.6
#2 0xb6228122 in sf::priv::WindowImplX11::WindowImplX11() ()
from /usr/lib/libsfml-window.so.1.6
#3 0xb622455d in sf::priv::WindowImpl::New() ()
from /usr/lib/libsfml-window.so.1.6
#4 0xb6220bf7 in sf::Context::Context() () from /usr/lib/libsfml-window.so.1.6
#5 0xb6220c70 in sf::Context::GetGlobal() ()
from /usr/lib/libsfml-window.so.1.6
#6 0xb6220cc7 in ?? () from /usr/lib/libsfml-window.so.1.6
#7 0xb622950d in ?? () from /usr/lib/libsfml-window.so.1.6
#8 0xb621ff68 in _init () from /usr/lib/libsfml-window.so.1.6
#9 0xb7ff070c in ?? () from /lib/ld-linux.so.2
#10 0xb7ff0829 in ?? () from /lib/ld-linux.so.2
#11 0xb7ff48c9 in ?? () from /lib/ld-linux.so.2
#12 0xb7ff0326 in ?? () from /lib/ld-linux.so.2
#13 0xb7ff4106 in ?? () from /lib/ld-linux.so.2
#14 0xb7f9dc0b in ?? () from /lib/libdl.so.2
#15 0xb7ff0326 in ?? () from /lib/ld-linux.so.2
#16 0xb7f9e09c in ?? () from /lib/libdl.so.2
#17 0xb7f9db41 in dlopen () from /lib/libdl.so.2
#18 0x081419aa in derelict.util.sharedlib.LoadSharedLib() ()
#19 0x08141adf in derelict.util.sharedlib.SharedLib.load() ()
#20 0x081415af in derelict.util.loader.SharedLibLoader.load() ()
#21 0x08141587 in derelict.util.loader.SharedLibLoader.load() ()
#22 0x081414e8 in derelict.util.loader.SharedLibLoader.load() ()
#23 0x080d0cdc in fluidity.visuals.window.Application.__ctor() ()
#24 0x080cf637 in D main ()
#25 0x08103716 in rt.dmain2.main() ()
#26 0x08103670 in rt.dmain2.main() ()
#27 0x0810375a in rt.dmain2.main() ()
#28 0x08103670 in rt.dmain2.main() ()
#29 0x08103616 in main () |
Any suggestions appreciated. |
|
| Back to top |
|
|
JNewt
Joined: 05 Jun 2008
Posts: 69
|
| Posted: Mon Oct 18, 2010 6:03 pm Post subject: |
|
|
OK, I have discovered something interesting about this problem: it doesn't occur if derelict.opengl.gl is not imported anywhere. Here's a test case:
| Code: | module sfmltest;
import std.stdio;
import derelict.sfml.window;
import derelict.opengl.gl;
void main()
{
DerelictSFMLWindow.load();
writeln("Loaded SFML");
int width = 800,
height = 600;
sfWindowSettings Settings = {24, 8, 0};
sfVideoMode Mode = {width, height, 32};
string title = "Lotus";
sfWindow* window = sfWindow_Create(Mode, title.ptr, sfResize|sfClose, Settings);
bool running = true;
while (running) {
sfEvent event;
while (sfWindow_GetEvent(window, &event)) {
if (event.Type == sfEvtClosed)
running = false;
}
assert(sfWindow_SetActive(window, true));
sfWindow_Display(window);
}
sfWindow_Destroy(window);
} |
This code seg faults.
Now, commenting out this line
| Code: | | import derelict.opengl.gl; |
...and it works. Frankly, I'm mystified. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sun Nov 21, 2010 7:32 am Post subject: |
|
|
This might be related to the bug discussed in a more recent thread regarding DerelictSDL on Linux. In which case, there is most likely a solution. But I'm hesitant to implement it until I can verify that there's no way around it.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
tbone
Joined: 05 Nov 2009
Posts: 19
|
| Posted: Mon Jan 10, 2011 1:12 pm Post subject: |
|
|
I am having the same issue, I think it has to do with libcsfml-window.so and libcsfml-graphics.so being linked to libGL and the X libraries.
When compiled with derelict.opengl.gl, glXGetConfig is an address inside of my binary.
When compiled without derelict.opengl.gl, glXGetConfig is at an address in shared library land.
Looking at the backtrace after the segfault, sf::priv::WindowImplX11::CreateContext calls glXGetConfig, which is the pointer to glXGetConfig not glXGetConfig itself.
Edit: Cause & Solution:
This is caused by the compiler (in my case gdc) passing -export-dynamic to the linker. -export-dynamic is if you want to export symbols, so my binary's version of 'glXGetConfig' is being exported to libcsfml instead of the proper glXGetConfig.
The solution is to link your binary *WITHOUT* -export-dynamic or -rdynamic passed to the linker.
Correction: It was caused by *ME* passing -rdynamic to gdc, it's not gdc's fault. |
|
| Back to top |
|
|
JNewt
Joined: 05 Jun 2008
Posts: 69
|
| Posted: Thu Jan 13, 2011 11:45 pm Post subject: |
|
|
| Thanks for putting me on the right track. I copied /etc/dmd.conf into my working directory and removed the -L--export-dynamic flag. No more seg faults. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
