#1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a
PPC Mac OS X 10.5 Leopard as part of GHC 6.9
-------------------------+--------------------------------------------------
Reporter: thorkilnaur | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: powerpc
Os: MacOS X |
-------------------------+--------------------------------------------------
Comment (by thorkilnaur):
I have reduced the size of the assembler file that tickles what I still
believe is a Leopard linker error to this:
{{{
thorkil-naurs-mac-mini:split438 thorkilnaur$ cat g17.s
.const_data
.align 2
_parseczm2zi0_TextziParserCombinatorsziParsecziToken_makeTokenParser_srt:
.long 0
.text
.align 2
.long
_parseczm2zi0_TextziParserCombinatorsziParsecziToken_makeTokenParser_srt-(_s58i_info)+24
_s58i_info:
.long 0
.symbol_stub
L_u_iswalpha$stub:
.indirect_symbol _u_iswalpha
lis r11,ha16(L_u_iswalpha$lazy_ptr)
lwz r12,lo16(L_u_iswalpha$lazy_ptr)(r11)
mtctr r12
addi r11,r11,lo16(L_u_iswalpha$lazy_ptr)
bctr
.lazy_symbol_pointer
L_u_iswalpha$lazy_ptr:
.indirect_symbol _u_iswalpha
.long dyld_stub_binding_helper
.subsections_via_symbols
thorkil-naurs-mac-mini:split438 thorkilnaur$
}}}
I get the Bus error as follows:
{{{
thorkil-naurs-mac-mini:split438 thorkilnaur$ gcc -c g17.s
thorkil-naurs-mac-mini:split438 thorkilnaur$ ld -r g17.o
Bus error
thorkil-naurs-mac-mini:split438 thorkilnaur$
}}}
Here are some things that I can do that removes the Bus error reaction:
* Change the initial {{{.const_data}}} to {{{.text}}}.
* Change {{{.long
_parseczm2zi0_TextziParserCombinatorsziParsecziToken_makeTokenParser_srt-(_s58i_info)+24}}}
to {{{.long 0}}}.
* Remove the entire tail of the file that begins with {{{.symbol_stub}}}.
http://www.haskell.org/pipermail/glasgow-haskell-
users/2007-November/013447.html reports that:
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.
This is confirmed by the behaviour of the Leopard linker compared to the
Tiger linker, in particular the wording of error messages when reporting
on the same error.
I have not found a way to replace {{{ld}}} by {{{ld_classic}}} in the GHC
build process. I have tried:
* looking for ways to make gcc use ld_classic and, in turn, GHC call gcc
to make this happen. I have not found such a way.
* creating a static link earlier than ld in the path that points to
ld_classic, but this fails to replace the ld uses by gcc
* replacing the link {{{/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld
-> ../../../../bin/ld}}}, but that causes GHC configure (and also ordinary
gcc compiles) to fail with
{{{
/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld: /usr/lib/gcc/powerpc-
apple-darwin9/4.0.1/../../../libSystem.dylib unknown flags (type) of
section 9 (__TEXT,__dof_plockstat) in load command 0
/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld:
/usr/lib/libSystem.B.dylib unknown flags (type) of section 9
(__TEXT,__dof_plockstat) in load command 0
collect2: ld returned 1 exit status
}}}
The basic problem that the Leopard linker apparently fails to solve in
some cases is the evaluation of the expression
{{{_parseczm2zi0_TextziParserCombinatorsziParsecziToken_makeTokenParser_srt-(_s58i_info)+24}}}
in line 7 of g17.s. The two symbols are defined in different sections
(.const_data and .text, respectively) which seems significant. But whether
this indicates any reasonable workaround in, say, the GHC code generator,
I cannot tell.
In any case, I would welcome some ideas about further directions for this
investigation. I will happily supply any additional details.
Best regards
Thorkil
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1958#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
