Christian: Is it possible that you might have code compiled with an older version of ghc lying around in an odd place in your build hierarchy? I would imagine that you upgraded cabal-installed packages. If for some reason you copied or used rsync to replicate a directory tree onto the older machine, then that would explain why you are seeing these difficulties.
-scooter Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Simon Marlow <marlo...@gmail.com> Sender: glasgow-haskell-users-boun...@haskell.org Date: Wed, 25 Aug 2010 16:39:43 To: Christian Maeder<christian.mae...@dfki.de> Cc: <glasgow-haskell-users@haskell.org> Subject: Re: __emutls_get_address link problem On 25/08/2010 16:37, Christian Maeder wrote: > Christian Maeder schrieb: >> Simon Marlow schrieb: >>> On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 8/23/10 11:57 , Christian Maeder wrote: >>>>> However, when I try to compile the simplest source with on older >>>>> gcc-3.4.4 I get the link error below, but only for the threaded rts! >>>>> >>>>> With ghc-6.12.1 and gcc-4.x.y (x< 3) I did not have such a problem when >>>>> switching to a machine that only has gcc-3.4.4. >>>> You got lucky; mixing GCC major versions like that is not expected (much >>>> less guaranteed) to work in general. GCC evidently changed the way it >>>> implements some thread support routines between gcc3 and gcc4. > > Why should it not be possible to create object files (like also dynamic > libs) with (very) different compilers? This is a case where the ABI changed between versions of gcc (I presume). It rarely happens with C code, but happens more often with C++, and, of course, in GHC we change the ABI with every single release so you should be used to this by now :-) >>> In particular, thread-local variables, which are used by the parallel GC. >> >> I'm just testing if I get runtime problems, but the linking error goes >> away, if I put libgcc_eh.a from gcc-4.3.3 into ghc's libdir. > > The hack seems to work, although it looks dangerous regarding other > symbols from libgcc_eh.a that should be in sync with the used gcc-3.4.4. I wouldn't trust it. Why do you need to mix code compiled by two different gcc versions? Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users