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 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

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 mailto:haskell@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@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