On Mon, 2009-06-01 at 20:05 +0200, Sven Panne wrote: > [ 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 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 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? > 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? I rather suspect it's freeglut doing something dubious with comparing function pointers. > 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? 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. Duncan _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
