Build failures making GHC 6.8.1 on PPC Mac Os X 10.5

[Corey O'Connor]

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>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071111/b8e4220b/attachment.htm