problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC
home page
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Thu Feb 14 05:36:23 EST 2008
Christian Maeder:
> Chris Kuklewicz wrote:
>> The "./setup build" causes a segmentation fault. This is for every
>> project I try (including ones with very default Setup.hs contents).
>
> I can at least reproduce the segmentation fault by running my PPC-
> Tiger
> binary on an i386-Leopard, by compiling with additional options
> "-optc-arch -optcppc -opta-arch -optappc -optl-arch -optlppc".
>
> m29:fastcgi-3001.0.1 maeder$ ghc -opta-arch -optappc -optl-arch -
> optlppc
> --make Setup.lhs
> Linking Setup ...
> m29:fastcgi-3001.0.1 maeder$ ./Setup configure
> Configuring fastcgi-3001.0.1...
> Warning: No license-file field.
> m29:fastcgi-3001.0.1 maeder$ ./Setup build
> Segmentation fault
I can't see how ghc can generate a correct executable if you pass
these cross-compilation options to GHC. Even if you can get GHC to
generate proper PPC code, it will link against *Haskell* libraries
that contain i386 code. (The options -optl-arch -optlppc will give
you the PPC versions of the system libraries, but not the GHC
packages.) Or am I missing something?
> and even (after adding the above options to the bin/ghc-6.8.2 script)
>
> m29:fastcgi-3001.0.1 maeder$ runghc Setup.lhs build
> Preprocessing library fastcgi-3001.0.1...
> Building fastcgi-3001.0.1...
> [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs,
> dist/build/Network/FastCGI.o )
> ar: creating archive dist/build/libHSfastcgi-3001.0.1.a
> ld: atom sorting error for
> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and
> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in
> dist/build/Network/FastCGI.o
> ld: atom sorting error for
> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and
> _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in
> dist/build/Network/FastCGI.o
According to Wolfgang Thaller's answer to a previous post by yourself,
these atom sorting errors are harmless:
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013988.html
Manuel
More information about the Glasgow-haskell-users
mailing list