renderString not working in ghci
Hi all, 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? Gr. Matthijs (Please CC me, I'm not subscribed)
Hi all,
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).
It might be that this problem is amd64 specific. When running on a very similar setup on another i386 machine, font rendering works fine in both ghci and ghc. Gr. Matthijs
Am Mittwoch, 20. Mai 2009 13:50:45 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).
It might be that this problem is amd64 specific. When running on a very similar setup on another i386 machine, font rendering works fine in both ghci and ghc.
I can reproduce this on openSUSE x86_64 with Misc/ARBOcclude from the GLUT examples, too: Compiling + runnning works, loading the example into GHCi and evaluation main leads to "freeglut (<interactive>): font 0x40c79328 not found". I'll take a look when I find some time, but I am not 100% sure if this a bug in the GLUT package or GHCi. Has this been cross-posted to ghc-bugs? Cheers, S.
found". I'll take a look when I find some time, but I am not 100% sure if this a bug in the GLUT package or GHCi. Has this been cross-posted to ghc-bugs? Nope, me neither. The way of specifying fonts is slightly funky in glut to start with...
I haven't posted this to any other list yet, first wanted to ask around here. I'll see if I can post this to ghc-bugs as well next week (woohoo, yet another list to subscribe to :-p). Gr. Matthijs
[ 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.
participants (2)
-
Matthijs Kooijman -
Sven Panne