#3260: Linking stage2 on PPC gives "scattered reloc r_address too large"
---------------------------------+------------------------------------------
Reporter: benl | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: 6.13
Keywords: | Difficulty: Unknown
Os: MacOS X | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by PHO):
> Does that mean using -fPIC would fix this?
That sounds possible in theory, but doesn't do the trick.
GHCi libraries compiled with -fPIC still cause the following error:
{{{
...
/VectMonad.o compiler/stage2/build/VectType.o compiler/stage2/build
/VectUtils.o compiler/stage2/build/Vectorise.o compiler/stage2
/build/parser/cutils.o compiler/stage2/build/utils/md5.o
`/usr/bin/find compiler/stage2/build -name "*_stub.o" -print`
ld: scattered reloc r_address too large for inferred architecture ppc
gmake[1]: *** [compiler/stage2/build/HSghc-6.13.20100516.o] Error 1
}}}
Each object files (like "compiler/stage2/build/Vectorise.o") has
section based relocation entries regardless of whether they are
compiled with -fPIC or not. That is, any references to external
sections (including instructions in an !__text section referring to a
symbol pointer in an !__picsymbolstub1 section) have their respective
relocation entries. This is normal and necessary because ld(1) needs
such relocation entries to merge objects and produce a dynamic library
(or a merged object) by merging many sections, each from different
objects.
If the resulting library will not be a subject of any further static
linkage, section based relocation entries are no longer needed so
ld(1) happily removes them from the output, because sections in such
libraries will no longer change their sizes and segment-based
offsets. This is why ld(1) can produce dynamic libraries larger than
2^24^ - 1 bytes.
But when ld(1) produces a merged object file (like our static GHCi
libraries), ld(1) thinks ''the resulting object may be statically
linked with other objects again'' so it retains (possibly scattered)
section based relocation entries in the merged object file, hence the
"scattered reloc r_address too large" error. Indeed we know GHCi
libraries will not be merged any further, but there is no way to tell
ld(1) our intention.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3260#comment:15>
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
