Sven Panne wrote:
I'm currently trying to find out why a few GLUT examples work when they are
compiled by GHC, but not when they are run within GHCi (this happens e.g.
with GLUT/examples/Misc/ARBOcclude.hs). The main difference is that in the
former case libHSGLUT-XY.a is linked into the executable, and in the latter
case HSGLUT-XY.o is loaded/linked by GHCi when "main" is evaluated. Boiling
down the problem to plain C leads to:
------------ strange.c --------------------------
#include <dlfcn.h>
#include <GL/glut.h>
#include <stdio.h>
int main(void) {
void *handle = dlopen("libglut.so", RTLD_NOW | RTLD_GLOBAL);
printf("%p %p\n", dlsym(handle, "glutInit"), glutInit);
return dlclose(handle);
}
---------------------------------------------------
Compiling and running this on my x86_64 openSuSE 10.2 box yields:
---------------------------------------------------
[EMAIL PROTECTED]:~> gcc strange.c -ldl -lglut && ./a.out
0x2b0c26dd8740 0x400658
---------------------------------------------------
Huh??? Using -fpic seems to cure things:
---------------------------------------------------
[EMAIL PROTECTED]:~> gcc strange.c -ldl -lglut -fpic && ./a.out
0x2b58895d7740 0x2b58895d7740
---------------------------------------------------
I don't have a clue what is going on here, and this phenomenon is not
GLUT-related at all, one could use e.g. "cos" from "libm.so", resulting in
basically the same strange behaviour. Are there any dynamic linking
grandmasters on this list who can enlighten me?
When you generate a non-PIC object file, references to external functions
will go through the PLT (a table of jump instructions, or it might be more
complicated than that and support lazy resolution). So when you use
dlsym() you're getting the real address of the function, but the static
binding is pointing to an entry in the PLT. I guess the -fPIC version is
doing the indirection at the point of the symbol reference. This might help:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
