problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page

Manuel M T Chakravarty chak at
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:


More information about the Glasgow-haskell-users mailing list