RE: [Template-haskell] Templates + FFI + shared libs = segfault?
On 07 May 2004 00:09, Robert Dockins wrote:
That appears to be the case. ghci crashes just loading the .so (listings below). After playing around, the problem seems to be with loading the dependancies. If I load -lqt also (very carefully), then ghci doesn't crash, and, in fact, the origninal TH module also loads and works with the correct command line. In short here is the scoop:
ghci -lsmokeqt segfault ghci -lqt -lsmokeqt can't find .so ghci -L/usr/qt/3/lib -lqt -lsmokeqt works! ghci -L/usr/qt/3/lib -lsmokeqt -lqt segfaults ghci -lqt can't find .so ghci -L/usr/qt/3/lib -lqt works
Before we dig into this, could you try a simple C program which just calls dlopen() on smokeqt, and see if that fails? It looks from your diagnosis that this is perhaps not related to GHC at all, but something between the dynamic linker and smoke.
So, it appears that libqt.so (or libqt-mt.so also works) must be loaded before libsmokeqt.so. The same thing occurs when I insert the above options into the command line to compile my TH module.
I am attaching output from LD_DEBUG=files listings from three different situations
1) ldrun.txt output from a simple program which uses smoke 2) ghcismokeqt.txt output from ghci -lsmokeqt 3) ghciqtsmokeqt.txt output from ghci -L/usr/qt/3/lib -lqt-mt -lsmokeqt
2) is the interesting one. It cuts off after calling init on libsmokeqt.so. It also contains an error while binding the symbol 'pthread_key_create' in the libGL module, which looks very odd. I can only assume this is related somehow. The error in question looks like:
12500: /usr/X11R6/lib/libGL.so.1: error: relocation error: undefined symbol: pthread_key_create (fatal)
This error does not occur in 1) nor in 3).
Perhaps the linker is failing to load a dependency? Cheers, Simon
Greetings, So, the good news is that this isn't a GHC bug. The bad news is I've wasted your time. The segfault occurs on dlopen()ing the .so in a simple C driver program. I'm getting the same relocation error already reported, and it appears to segfault in the same place. As this is a gentoo system, I'm going to recomple my X11 and see if that makes the weird GL linking error go away; its possible my compiler is out of sync with the X11 binaries or something slightly odd like that. Failing that, I'll take it up with the smoke people. Thank you all for your help. Robert Dockins On Fri, 2004-05-07 at 04:54, Simon Marlow wrote:
On 07 May 2004 00:09, Robert Dockins wrote:
That appears to be the case. ghci crashes just loading the .so (listings below). After playing around, the problem seems to be with loading the dependancies. If I load -lqt also (very carefully), then ghci doesn't crash, and, in fact, the origninal TH module also loads and works with the correct command line. In short here is the scoop:
ghci -lsmokeqt segfault ghci -lqt -lsmokeqt can't find .so ghci -L/usr/qt/3/lib -lqt -lsmokeqt works! ghci -L/usr/qt/3/lib -lsmokeqt -lqt segfaults ghci -lqt can't find .so ghci -L/usr/qt/3/lib -lqt works
Before we dig into this, could you try a simple C program which just calls dlopen() on smokeqt, and see if that fails? It looks from your diagnosis that this is perhaps not related to GHC at all, but something between the dynamic linker and smoke.
So, it appears that libqt.so (or libqt-mt.so also works) must be loaded before libsmokeqt.so. The same thing occurs when I insert the above options into the command line to compile my TH module.
I am attaching output from LD_DEBUG=files listings from three different situations
1) ldrun.txt output from a simple program which uses smoke 2) ghcismokeqt.txt output from ghci -lsmokeqt 3) ghciqtsmokeqt.txt output from ghci -L/usr/qt/3/lib -lqt-mt -lsmokeqt
2) is the interesting one. It cuts off after calling init on libsmokeqt.so. It also contains an error while binding the symbol 'pthread_key_create' in the libGL module, which looks very odd. I can only assume this is related somehow. The error in question looks like:
12500: /usr/X11R6/lib/libGL.so.1: error: relocation error: undefined symbol: pthread_key_create (fatal)
This error does not occur in 1) nor in 3).
Perhaps the linker is failing to load a dependency?
Cheers, Simon
participants (2)
-
Robert Dockins -
Simon Marlow