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."<br><br>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:
<br><br>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.
<br><br>1. Once ld from ld64 is compiled for debug swap out the production ld with the version with debug symbols.<br>2. ulimit -c unlimited<br>3. Run ghc's make once again.<br>4. Load the core dump in GCC<br><br>This gives the interesting back trace:
<br>#0 0x000222ac in ObjectFile::Section::getBaseAddress (this=0x0) at ObjectFile.h:182<br>#1 0x000224a0 in ObjectFile::Atom::getAddress (this=0x6decb0) at ObjectFile.h:269<br>#2 0x000c3a30 in mach_o::executable::Writer<ppc>::addObjectRelocs_powerpc (this=0x6f65a0, atom=0x6dea30, ref=0x6f34a0) at
MachOWriterExecutable.hpp:2742<br>#3 0x0001309c in mach_o::executable::Writer<ppc>::addObjectRelocs (this=0x6f65a0, atom=0x6dea30, ref=0x6f34a0) at MachOWriterExecutable.hpp:2678<br>#4 0x001ab3e4 in mach_o::executable::Writer<ppc>::buildObjectFileFixups (this=0x6f65a0) at
MachOWriterExecutable.hpp:3065<br>#5 0x001be094 in mach_o::executable::Writer<ppc>::buildFixups (this=0x6f65a0) at MachOWriterExecutable.hpp:2398<br>#6 0x001be108 in mach_o::executable::Writer<ppc>::buildLinkEdit (this=0x6f65a0) at
MachOWriterExecutable.hpp:1834<br>#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<br>#8 0x0000fec4 in Linker::writeOutput (this=0xbffef608) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:2700<br>#9 0x0001f5b0 in Linker::link (this=0xbffef608) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:585
<br>#10 0x0002113c in main (argc=465, argv=0xbffefb88) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:3568<br><br>Looks like a NULL pointer dereference. Why the pointer is NULL I don't know but that's what I have so far.
<br><br>-Corey<br><br><div class="gmail_quote">On Nov 11, 2007 7:33 AM, Chris Kuklewicz <<a href="mailto:haskell@list.mightyreason.com" target="_blank">haskell@list.mightyreason.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>Ian Lynagh wrote:<br>> On Fri, Nov 09, 2007 at 08:21:09PM -0800, Corey O'Connor wrote:<br>>> Anytime I see the linker crash I get nervous. Any clues on where to start<br>>> debugging?
<br>><br>> Is it deterministic? A hardware fault, e.g. bad RAM, seems likely to me.<br>><br>><br>> Thanks<br>> Ian<br><br></div></div>I got the same Bus Error in compiling Parsec (as part of extralibs) with OS X
<br>10.5 / XCode 3.0 on a single G4 ppc computer (powerbook).<br><br>I fear the new Apply toolchain is choking on something, possible split-objs?<br><br>--<br><font color="#888888">Chris Kuklewicz<br></font></blockquote>
</div>
<br><br clear="all"><br>-- <br>-Corey O'Connor