Build failures making GHC 6.8.1 on PPC Mac Os X 10.5

Deborah Goldsmith dgoldsmith at mac.com
Tue Nov 13 10:24:23 EST 2007


1437 appears to be gone with ghc-6.8.1 and 10.5 GM. I've commented the  
bug.

Deborah

On Nov 13, 2007, at 3:14 AM, Simon Marlow wrote:

> There seem to be several issues arising with GHC 6.8.1 on MacOS X  
> with various combinations of 10.4/10.5/x86/PPC.  So that we don't  
> lose track, can someone (or someones) create the relevant tickets  
> and keep them updated?  To start with, here are the current tickets  
> open for MacOS:
>
> http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=milestone&os=MacOS+X&order=priority
>
> In particular, #1437 is quite old, I'd like to know whether it is  
> still a problem with 6.8.1:
>
> http://hackage.haskell.org/trac/ghc/ticket/1437
>
> Cheers,
> 	Simon
>
> Corey O'Connor wrote:
>> Split objects does seem to be the source of the crash. With it  
>> disabled the compile of Parsec succeeds but linking of System fails  
>> due to "unknown scattered relocation type 4."
>> I decided to compile the ld tool with debugging to see if I can get  
>> more information when ld crashes. Here's what I've found out so far:
>> The ld executable used is actually from the ld64 project and not  
>> the cctools project. The cctools' ld is installed as ld_classic on  
>> OS X. In theory this should be the same linker as on Tiger and  
>> could be used instead of the ld from ld64. That might be a good  
>> workaround till ld is fixed: Update ghc's SysTools to use  
>> ld_classic instead of ld.
>> 1. Once ld from ld64 is compiled for debug swap out the production  
>> ld with the version with debug symbols.
>> 2. ulimit -c unlimited
>> 3. Run ghc's make once again.
>> 4. Load the core dump in GCC
>> This gives the interesting back trace:
>> #0  0x000222ac in ObjectFile::Section::getBaseAddress (this=0x0) at  
>> ObjectFile.h:182
>> #1  0x000224a0 in ObjectFile::Atom::getAddress (this=0x6decb0) at  
>> ObjectFile.h:269
>> #2  0x000c3a30 in  
>> mach_o::executable::Writer<ppc>::addObjectRelocs_powerpc  
>> (this=0x6f65a0, atom=0x6dea30, ref=0x6f34a0) at  
>> MachOWriterExecutable.hpp:2742
>> #3  0x0001309c in mach_o::executable::Writer<ppc>::addObjectRelocs  
>> (this=0x6f65a0, atom=0x6dea30, ref=0x6f34a0) at  
>> MachOWriterExecutable.hpp:2678
>> #4  0x001ab3e4 in  
>> mach_o::executable::Writer<ppc>::buildObjectFileFixups  
>> (this=0x6f65a0) at MachOWriterExecutable.hpp:3065
>> #5  0x001be094 in mach_o::executable::Writer<ppc>::buildFixups  
>> (this=0x6f65a0) at MachOWriterExecutable.hpp:2398
>> #6  0x001be108 in mach_o::executable::Writer<ppc>::buildLinkEdit  
>> (this=0x6f65a0) at MachOWriterExecutable.hpp:1834
>> #7  0x001be238 in mach_o::executable::Writer<ppc>::write  
>> (this=0x6f65a0, atoms=@0xbffef940, stabs=@0xbffef9c4,  
>> entryPointAtom=0x0, dyldHelperAtom=0x0, createUUID=false,  
>> canScatter=false, cpuConstraint=ObjectFile::Reader::kCpuAny,  
>> biggerThanTwoGigs=false) at MachOWriterExecutable.hpp:1814
>> #8  0x0000fec4 in Linker::writeOutput (this=0xbffef608) at /Users/ 
>> coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:2700
>> #9  0x0001f5b0 in Linker::link (this=0xbffef608) at /Users/coconnor/ 
>> Development/External_projects/Darwin/ld64-77/src/ld.cpp:585
>> #10 0x0002113c in main (argc=465, argv=0xbffefb88) at /Users/ 
>> coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:3568
>> Looks like a NULL pointer dereference. Why the pointer is NULL I  
>> don't know but that's what I have so far.
>> -Corey
>> On Nov 11, 2007 7:33 AM, Chris Kuklewicz <haskell at list.mightyreason.com 
>>  <mailto:haskell at list.mightyreason.com>> wrote:
>>    Ian Lynagh wrote:
>>     > On Fri, Nov 09, 2007 at 08:21:09PM -0800, Corey O'Connor wrote:
>>     >> Anytime I see the linker crash I get nervous. Any clues on  
>> where
>>    to start
>>     >> debugging?
>>     >
>>     > Is it deterministic? A hardware fault, e.g. bad RAM, seems  
>> likely
>>    to me.
>>     >
>>     >
>>     > Thanks
>>     > Ian
>>    I got the same Bus Error in compiling Parsec (as part of  
>> extralibs)
>>    with OS X
>>    10.5 / XCode 3.0 on a single G4 ppc computer (powerbook).
>>    I fear the new Apply toolchain is choking on something, possible
>>    split-objs?
>>    --
>>    Chris Kuklewicz
>> -- 
>> -Corey O'Connor
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



More information about the Glasgow-haskell-users mailing list