(Imported from Trac #791, reported by @batterseapower on 2011-01-18)
cabal unpack highlighting-kate-0.2.8.1
ghc --make Setup.hs
ld: scattered reloc r_address too large for inferred architecture i386
Cabal's GHC.hs should not use combineObjectFiles on with GHC >= 7 and OS X.
(Imported comment by @batterseapower on 2011-01-18)
OK, now I'm not sure if this is in fact a GHC bug as well, because I tried to work around with:
sudo ./Setup install
*Main> :m Text.Highlighting.Kate.Syntax
Prelude Text.Highlighting.Kate.Syntax> languages
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package filepath-184.108.40.206 ... linking ... done.
Loading package parsec-220.127.116.11 ... linking ... done.
Loading package bytestring-0.9.1.8 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-18.104.22.168 ... linking ... done.
Loading package regex-base-0.93.2 ... linking ... done.
Loading package regex-pcre-builtin-0.94.2.1.7.7 ... linking ... done.
Loading package xhtml-3000.2.0.1 ... linking ... done.
Loading package highlighting-kate-0.2.8.1 ... <interactive>: mmap 0 bytes at 0x0: Invalid argument
<interactive>: Try specifying an address with +RTS -xm<addr> -RTS
Is this expected behaviour?
(Imported comment by @dcoutts on 2011-01-18)
Ah, you mean it is OK to omit the .o files on OSX with ghc-7 because ghci now will look at the .a files instead. Does that apply on all platforms or just OSX? If we can avoid making ghci .o libs on all arches then that's even better.
It was my understanding that GHCi will use the .a on all platforms - so you could disable it unconditionally for GHC >= 7. See the patch at http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=20101127173000-3fd76-04f98172935bf6b1a3f4154d57c06f620b6b9427.gz for details.
However, I'm having some problems making it actually work (as you can see above). I've filed GHC #4901 (http://hackage.haskell.org/trac/ghc/ticket/4901) to get feedback on whether my understanding at fault or GHCi is.
Current decision of ghc devs is not to disable GHCi .o libs yet because of possible bugs in loading the .a archives.
When we do change it, we can use this patch:
hunk ./Distribution/Simple/GHC.hs 542
- ifGHCiLib = when (withGHCiLib lbi && withVanillaLib lbi)
- ifGHCiLib = when (withGHCiLib lbi && withVanillaLib lbi
- -- As of GHC 7, GHCi can load .a libs, so the .o
- -- libs are not necessary. However this only works
- -- correctly in later releases of the ghc-7.x
- && compilerVersion comp < Version [7,0,unknown] )
In the meantime, the workaround for affected packages is to use the flag --disable-library-for-ghci.
(Imported comment by @igfoo on 2011-01-19)
I don't think you should override withGHCiLib, just change the default.
(Imported comment by @conal on 2011-01-19)
I just ran into this same issue while 'cabal install'ing highlighting-kate-0.2.9 with 32-bit ghc 7.0.2 on Mac OS 10.6.6. Is there an up-to-date recommendation for this problem?
bash-3.2$ cabal install
Preprocessing library highlighting-kate-0.2.9...
Preprocessing executables for highlighting-kate-0.2.9...
[ 1 of 111] Compiling Paths_highlighting_kate ( dist/build/autogen/Paths_highlighting_kate.hs, dist/build/Paths_highlighting_kate.o )
[111 of 111] Compiling Text.Highlighting.Kate ( Text/Highlighting/Kate.hs, dist/build/Text/Highlighting/Kate.o )
ld: scattered reloc r_address too large
cabal: Error: some packages failed to install:
highlighting-kate-0.2.9 failed during the building phase. The exception was:
bash-3.2$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.2
bash-3.2$ uname -a
Darwin Conals-Mac.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386
(Imported comment by @batterseapower on 2011-03-21)
The archive-loading bug is fixed upstream. For now you have to work around the issue by installing the library with --disable-library-for-ghci, so GHCi won't work with such a library. When the new GHC comes out you will get GHCi support, but you will still to use --disable-library-for-ghci in order to install the package in the first place.
When Cabal stops generating the GHCi object file by default we will stop trying to link large objects and hence this error will be a non-issue.
(Imported comment by @dcoutts on 2011-04-05)
If the GHC devs think it's really fixed then I'm happy to have Cabal stop generating GHCi .o files at all, either on all arches, or just on OSX, for GHC version > whatever. I don't want to do something dubious like making failure to generate .o files non-fatal and just warn.
I just built this same package and version (highlighting-kate-0.2.8.1) on an OS X machine without a problem. I propose we close this ticket as something that has probably been fixed in Cabal or GHC sometime in the last few years since there is no other activity since May 2012, but please re-open if you're still having this problem.
Below is my machine info and the build output:
justin ~/Code/cabal $ uname -a
Darwin uio-mbp-02.local 14.1.0 Darwin Kernel Version 14.1.0: Mon Dec 22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 x86_64
justin ~/Code/cabal $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
justin /tmp/testit $ cabal sandbox init
Writing a default package environment file to
Creating a new sandbox at /private/tmp/testit/.cabal-sandbox
justin /tmp/testit $ cabal install highlighting-kate-0.2.8.1
Notice: installing into a sandbox located at
justin /tmp/testit $ echo $?