Skip to content

Linker error makes it impossible to use a stack-provided ghc #2712

@berdario

Description

@berdario
Contributor

This can be easily fixed in your GHC installation:

sed -i 's/-fno-PIE/-no-pie/g' ~/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/settings

Hopefully a fixed bindist (or the newer GHC 8.0.2 which ships with this fix already) will be released soon

Steps needed to support Linux distributions that enable PIE by default (Ubuntu 16.10, Debian Sid, etc.)

  • Release Stack 1.2.1
    Discover hsc2hs/config build errors cause (edit: maybe hsc2hs uses autotools directly? anyhow now we have a solution)
    Prepare new ghc nopie build to fix the hsc2hs errors?

Old issue description:

This it the same issue that I reported in this other ticket, but I now realized that my "fix" of removing ~/.stack/programs/x86_64-linux/ghc-8.0.1/ actually brought stack in an inconsistent state... and without it being aware of it, it was always selecting the system-installed ghc.

I thus moved away the whole ~/.stack/ directory, and tried to setup again... I tried both with lts version 7 and 6 (with --no-system-ghc), and the setup of ghc fails at linking step with both versions

I'm running Ubuntu 16.10, and I'm running

gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
GNU ld (GNU Binutils for Ubuntu) 2.27

The error is the same as in the other ticket, which I'll link again here

Stack version

Version 1.2.0 x86_64 hpack-0.14.0

Method of installation

Installed into ~/.local/bin/ via stack upgrade

Activity

berdario

berdario commented on Oct 16, 2016

@berdario
ContributorAuthor

I think this might be the cause:

https://wiki.ubuntu.com/SecurityTeam/PIE

mgsloan

mgsloan commented on Oct 17, 2016

@mgsloan
Contributor

It seems likely that is the cause! Good sleuthing. I am using ubuntu 16.04, which is before the release with gcc hardening. I have ld-2.26.1

What should be done about this? Linking is not something I am very familiar with. Do we need to have a way to compile everything -fPIC? Perhaps we need to use the --no-pie or --nopie option on new enough GCCs? Is handling this the responsibility of Cabal.

added this to the P2: Should milestone on Oct 17, 2016
berdario

berdario commented on Oct 17, 2016

@berdario
ContributorAuthor

I found that there are a few issues that have already been opened:

#2542

#2711

Frustratingly, all of them are now closed...

The good thing, is that a fix to add a ghc-build option to disable PIE has been committed:

e3aa238

The bad thing is... I don't have that flag in Stack 1.2.0 :/

I'm currently building stack from sources, hopefully it'll work

(regardless if it works, stack setup --no-system-ghc cannot work on Ubuntu 16.10 for stack <= 1.2.0 ... so that should at least be mentioned/documented)

mgsloan

mgsloan commented on Oct 17, 2016

@mgsloan
Contributor

Those issues were recently resolved, they are not yet in a released version of stack. Use stack built from the git repo to get the fix!

modified the milestones: Support, P2: Should on Oct 17, 2016
berdario

berdario commented on Oct 17, 2016

@berdario
ContributorAuthor

Yeah, I tried it out.... it almost works

I'm not yet sure if the detection is broken... I'll test that soon

Anyhow, building my project still fails:

Configuring memory-0.13...
Building memory-0.13...
Preprocessing library memory-0.13...
/usr/bin/ld: .stack-work/dist/x86_64-linux-nopie/Cabal-1.24.0.0/build/Data/Memory/MemMap/Posix_hsc_make.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
linking .stack-work/dist/x86_64-linux-nopie/Cabal-1.24.0.0/build/Data/Memory/MemMap/Posix_hsc_make.o failed (exit code 1)
command was: /usr/bin/gcc .stack-work/dist/x86_64-linux-nopie/Cabal-1.24.0.0/build/Data/Memory/MemMap/Posix_hsc_make.o .stack-work/dist/x86_64-linux-nopie/Cabal-1.24.0.0/build/Data/Memory/MemMap/Posix_hsc_utils.o -o .stack-work/dist/x86_64-linux-nopie/Cabal-1.24.0.0/build/Data/Memory/MemMap/Posix_hsc_make -fno-PIE -fno-stack-protector -L/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/bytestring-0.10.8.1 -Wl,-R,/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/bytestring-0.10.8.1 -L/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/deepseq-1.4.2.0 -Wl,-R,/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/deepseq-1.4.2.0 -L/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/array-0.5.1.1 -Wl,-R,/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/array-0.5.1.1 -L/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -Wl,-R,/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -L/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/integer-gmp-1.0.0.1 -Wl,-R,/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/integer-gmp-1.0.0.1 -lgmp -L/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/ghc-prim-0.5.0.0 -Wl,-R,/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/ghc-prim-0.5.0.0 -L/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/rts -Wl,-R,/home/dario/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/rts -lm -lrt -ldl

I guess that hsc2hs needs to be fixed as well
(this feels like a can of worms :/ )

berdario

berdario commented on Oct 17, 2016

@berdario
ContributorAuthor

I confirm that the autodetection for the correct build-type works correctly.

I'd have suggested to release 1.2.1 as soon as possible, but without the fixes for hsc2hs there'll still be plenty of people who will find themselves unable to build their projects

hvr

hvr commented on Oct 25, 2016

@hvr

Does this occur with GHCs from https://launchpad.net/~hvr/+archive/ubuntu/ghc as well?

berdario

berdario commented on Oct 25, 2016

@berdario
ContributorAuthor

I got the build working with your ghc...
I'll try again to confirm by wiping my ~/.stack and rebuilding with the stack-supplied's ghc

sgraf812

sgraf812 commented on Oct 25, 2016

@sgraf812
Contributor

Since about a week I'm experiencing strange build errors within Travis (and only there, not even in a local container): https://travis-ci.org/sgraf812/feed-gipeda/jobs/170090429

This also happens for previously green builds (e.g. from 2 months ago) when I restart them, but only my LTS-2.22 and LTS-6.2* builds are affected, the LTS-3.* and LTS-7.* builds are fine.

Is this related?

86 remaining items

t3hmrman

t3hmrman commented on Nov 5, 2017

@t3hmrman

Just ran into this issue on arch, trying to build a project that had been building fine up until now. After checking this issue and #3518 , What worked for me was a slight variation of @Gzernov 's process above:

  1. Download statically linked stack from stackage
  2. Use downloaded stack to enter ghci (by running stack ghci)

That worked for me, but unfortunately, stack build still didn't produce anything (it produced a file named a.out once I believe, but not consistently, and it seems to be ignoring the project configuration).

After that I remembered that I have --static specified in my .cabal file ld-options, and thought maybe removing that might help, and avoid trying to even do a static build at all locally (it didn't help).

Luckily for me when it's time to actually deploy I build my project inside a docker container (and during local development run from GHCI), so being able to start GHCI is enough for me as far as local development goes.

UPDATE - stack build does seem to work properly with statically linked stack executable after a while... I just used stack ghci as normal and after a while stack build produced the output I'd expect (and built the expected executables). Sorry I don't have a better timeline of what I actually did that might have affected stack build.

pera

pera commented on Nov 10, 2017

@pera

@t3hmrman I think the problem in Arch started a month ago after this change to the ncurses package.

Check senorhesles's workaround: adding "-no-pie" did the trick for me.

mkoloberdin

mkoloberdin commented on Nov 18, 2017

@mkoloberdin

@Gzernov, @t3hmrman, @pera The following workaround alleviates this issue on Arch Linux:

Install ghc with:

stack setup --ghc-build=ncurses6

Then add ghc-build: ncurses6 to ~/.stack/config.yaml, otherwise stack will try to download and install the tinfo6-nopie build on every attempt to use stack.

schoettl

schoettl commented on Nov 28, 2017

@schoettl

This problem still exists on Arch with current stack 1.5.1 and GHC 8.0.2.

I had to change this in the settings file:

vi ~/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/settings 
- ("C compiler flags", "-fno-PIE -fno-stack-protector"),
+ ("C compiler flags", "-no-pie -fno-stack-protector"),

Before I found this solution, I desperately removed everything related to xmonad, haskell, stack, cabal, ghc, including ~/.stack, ~/.cabal. Then I installed only stack and tried stack --install-ghc; stack install xmonad. The second command failed at the setlocale package with weired ld related errors. After the changed the settings file everything worked.

drvink

drvink commented on Dec 20, 2017

@drvink

I'm having this problem with Arch and Stack 1.6.1 with ghc 8.2.2 as well. Changing to -no-pie as mentioned in #2712 (comment) fixes the issue for me.

chrissound

chrissound commented on Dec 24, 2017

@chrissound

Adding ghc-build: nopie to ~/.stack/config.yaml fixed this for me.. Not sure if it's the same issue...

borsboom

borsboom commented on Dec 24, 2017

@borsboom
Contributor

@chrissound, @drvink: This is being discussed in #3518.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @ahri@mgsloan@enolan@cblp@luispedro

        Issue actions

          Linker error makes it impossible to use a stack-provided ghc · Issue #2712 · commercialhaskell/stack