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

[berdario]

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

[berdario]

I think this might be the cause:

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

[mgsloan]

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.

[berdario]

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]

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!

[berdario]

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]

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]

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

[berdario]

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]

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?