Am Montag, 1. Juni 2009 22:48:56 schrieb Duncan Coutts:
I don't know how the problem reported in that message is related to the renderString problem (which I do not understand), but the behaviour you see there is not terribly surprising. It's an artefact of the way dynamic linking works and should not generally cause any problems.
The word "generally" is a problem in itself. ;-) The main point is that GHCi'l dynamic linker behaves differently from the system's dynamic linker, so this is a very good reason to consider this a bug. It might not surface very often, but it is nevertheless a different behaviour a.k.a. bug.
The only case where it should make a difference is if code is assigning any meaning to the address of functions, eg to compare them for identity. In that case going via a thunk will make a difference. Is that what freeglut is doing do you think?
It is not about the address of functions, it is about data addresses. Here is the relevant snippet from GLUT's/freeglut's header file for non-Windows platforms: ---------------------------------------------------------------------- /* * I don't really know if it's a good idea... But here it goes: */ extern void* glutStrokeRoman; extern void* glutStrokeMonoRoman; extern void* glutBitmap9By15; ... /* * Those pointers will be used by following definitions: */ # define GLUT_STROKE_ROMAN ((void *) &glutStrokeRoman) # define GLUT_STROKE_MONO_ROMAN ((void *) &glutStrokeMonoRoman) # define GLUT_BITMAP_9_BY_15 ((void *) &glutBitmap9By15) ... ---------------------------------------------------------------------- As you can see, GLUT's fonts are represented by the addresses of global variables. This might not be the nicest way to do this, but it has to be done for binary compatibility reasons and there is *nothing* dubious about this. Note that e.g. we are very lucky that "errno" is a macro for a function call on all platforms for which -fPIC is relevant, otherwise we would have the same problem with it, too. The GLUT Haskell package uses a simple C wrapper around these macros: ---------------------------------------------------------------------- void* hs_GLUT_marshalBitmapFont(int fontID) { switch (fontID) { case 0 : return GLUT_BITMAP_8_BY_13; case 1 : return GLUT_BITMAP_9_BY_15; case 2 : return GLUT_BITMAP_TIMES_ROMAN_10; case 3 : return GLUT_BITMAP_TIMES_ROMAN_24; case 4 : return GLUT_BITMAP_HELVETICA_10; case 5 : return GLUT_BITMAP_HELVETICA_12; case 6 : return GLUT_BITMAP_HELVETICA_18; } return (void*)0; } ---------------------------------------------------------------------- For reasons explained in great length in the mail thread quoted, GHCi's linker doesn't link the wrapper correctly on some platforms when -fPIC is not used for its compilation.
I rather suspect it's freeglut doing something dubious with comparing function pointers.
The only one doing dubious things is GHCi's dynamic linker... ;-)
On most platforms -fPIC imposes some overhead and so it is only used when it's advantageous or necessary. On most platforms code that will live in a shared library should or must be compiled with -fPIC. x86-64 is one of the few architectures where the overhead is relatively low.
So my question is again: Why is -fPIC not the default for GHC on x86_64? If we don't want the overhead, that's OK (any benchmark numbers?), but then GHC's documentation should really contain a big, fat warning that GHCi's dynamic linker gets cases like the one above wrong. Cheers, S.