[HOpenGL] renderString not working in ghci

[Sven Panne]

[ Reprise of an old GHCi problem, GHC HQ read on please... ]

Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman:
> I've been playing around with GLUT (latest version from hackage, on Debian)
> a bit yesterday and am having some troubles with renderString. It works
> fine when I compile a binary using ghc, but when running from ghci I get an
> error similar to the following (I don't have the actual error at hand atm).
>
> freeglut(<interactive>): font 0xsomething not found
>
> From looking at the freeglut code, it seems this means that the font
> pointer passed in does not match the address of any of the font variables
> in the library. I'm not completely sure how the linking works in ghci, but
> it appears that something goes wrong with dynamic linking?
>
> Is this a known problem, or does anyone have any pointers where to debug
> this?

After thinking about this for a while, I got a déjà vu feeling and browsed 
through old mails, and there it was, the thread about the arcane, dark corners 
of dynamic linking and position independent code, where (almost) no man has 
gone before: ;-)

   http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html

I think that we finally came to the conclusion that we *have* to compile code 
with -fPIC on some platforms, including x86_64, but looking at the verbose 
output of the build step of the GLUT package on x86_64, one can see that there 
is nothing PIC-related at all. Adding "--ghc-option=-fPIC" to Cabal's build 
step for the GLUT package makes ARBOcclude.hs (and renderString in general) 
work again.

So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC 
implicitly? Or is this a bug in my GLUT package's .cabal file? I have a 
tendency to believe the former possibility... Or asked the other way round: Is 
there a reason why -fPIC is not the default for GHC?

Cheers,
   S.