Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link errors on Fedora 23 #257

Closed
mboes opened this issue Aug 14, 2016 · 6 comments
Closed

Link errors on Fedora 23 #257

mboes opened this issue Aug 14, 2016 · 6 comments

Comments

@mboes
Copy link
Member

mboes commented Aug 14, 2016

[Originally reported by @djsamperi on ghc-dev@.]

On Fedora 23 one gets strange link errors, even when using ld.gold:

$ stack build inline-r
inline-r-0.9.0.0: configure
inline-r-0.9.0.0: build
Progress: 1/2
--  While building package inline-r-0.9.0.0 using:
      /root/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.5.0 build lib:inline-r --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /src/.stack-work/logs/inline-r-0.9.0.0.log

    Configuring inline-r-0.9.0.0...
    Preprocessing library inline-r-0.9.0.0...
    /usr/bin/ld: error: .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Foreign/R/Internal_hsc_make.o: requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
    /usr/bin/ld: error: .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Foreign/R/Internal_hsc_utils.o: requires dynamic R_X86_64_PC32 reloc against 'vprintf' which may overflow at runtime; recompile with -fPIC
    collect2: error: ld returned 1 exit status
    linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Foreign/R/Internal_hsc_make.o failed (exit code 1)
@mboes
Copy link
Member Author

mboes commented Aug 14, 2016

The problem is with Cabal's call to hsc2hs. Cabal tells hsc2hs to link to libR.so (even though it's not technically needed here). But linking with a dynamic library in general requires PIC. Yet Cabal doesn't tell hsc2hs to -fPIC. So the link fails.

A workaround is to set cc-options: -fPIC in inline-r.cabal. However, that then causes H to fail at link time... For some reason -fPIC and static linking is mutually exclusive. So you need to say ghc-options: -dynamic in H.cabal to force only dynamic linking.

Likely this is an upstream bug in Cabal. But we could add the above workarounds to the mainline code, provided it doesn't break anything on other platforms.

@mboes
Copy link
Member Author

mboes commented Aug 14, 2016

Note that the cc-options: -fPIC workaround poses problems. It means that all binaries that link against inline-r must now have ghc-options: -dynamic (including tests, etc). Lest the user be greeted with an incomprehensible linker message. On some distro's I've tested -fPIC doesn't demand -dynamic, but who knows when/where one requires the other.

So one option is to simply tell Fedora users to use --nix. They get a predictable linker version and a predictable GCC version. And we know that those versions used by --nix aren't plagued by the above issues.

@mboes
Copy link
Member Author

mboes commented Aug 15, 2016

On Fedora 23 one gets strange link errors, even when using ld.gold:

Some additional notes on how to reproduce:

$ hub clone tweag/HaskellR
$ docker run -it -v $(pwd)/HaskellR:/src
$ curl -sSL https://s3.amazonaws.com/download.fpcomplete.com/fedora/23/fpco.repo | tee /etc/yum.repos.d/fpco.repo
$ dnf install stack R pkgconfig
$ cd /src
$ stack setup && stack build H

@mboes
Copy link
Member Author

mboes commented Aug 15, 2016 via email

mboes added a commit that referenced this issue Sep 4, 2016
@mboes
Copy link
Member Author

mboes commented Sep 4, 2016

I'll close this is a wontfix. This is an upstream issue, likely in Cabal though possibly in hsc2hs. Cabal should be passing -fPIC whenever it's asking hsc2hs to link against a standard library. But then again maybe it's not so simple: if there's also a static library to link against then -fPIC might be harmful as we've seen above.

@mboes mboes closed this as completed Sep 4, 2016
@mboes
Copy link
Member Author

mboes commented Sep 4, 2016

Meanwhile, I've added a FAQ entry pointing to workarounds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant