search

commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
3.99k stars 843 forks source link

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

Closed berdario closed 7 years ago

berdario commented 8 years ago

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.)

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

denibertovic commented 7 years ago

I can confirm that with stack 1.3 and ghc installed by stack in "nopie" mode one still has to edit the .stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/settings file and add "-fPIC" to the c compiler flags in order for the memory package to compile properly.

robstewart57 commented 7 years ago

I've just been hit by this. Does this, or will this, affect every Ubuntu 16.10 user who is using GHC 8.0.1 as a stack resolver, without a system installed ghc-8.0.1 (i.e. relying stack to install ghc-8.0.1 with stack setup)? I would imagine that that's quite a number of stack users, no?

borsboom commented 7 years ago

This might be something we can fix in the GHC bindist itself (in default settings file).

Is there concensus here that sed -i 's/-fno-PIE/-no-pie/g' ~/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/settings is always the correct change?

jonashaag commented 7 years ago

@robstewart57 yes that's my exact setup (with Docker)

berdario commented 7 years ago

Oh, I just realized that @enolan suggestion is right on point (I previously overlooked his comment, not realizing that he explained the difference in upper/lower case and how it affects at what time the option is used)

berdario commented 7 years ago

@borsboom

If you install the release candidate of GHC8.0.2 you'll find that its settings file already uses -no-pie, so this seems to be indeed the accepted solution

https://github.com/commercialhaskell/stack/issues/2712#issuecomment-263164470

denibertovic commented 7 years ago

@berdario Do you know why I still had to add "-fPIC" as per my comment above?

berdario commented 7 years ago

@denibertovic

Do you mean "-fPIC" instead of "-no-pie", or do you mean why do you have to modify the settings file at all?

If the former: I don't know...

if the latter: it's expected, since the 8.0.1 bindist doesn't ship with the fix, yet (also, maybe -no-pie implies -fPIC? or maybe you're only talking about the error that you're getting?)

robstewart57 commented 7 years ago

Is this GHC 8.0.2 fix related? This GHC ticket was opened by @hvr 2 months ago.

https://ghc.haskell.org/trac/ghc/ticket/12755

denibertovic commented 7 years ago

@berdario I'm saying that even with latest stack which installs ghc with "no-pie" (which you can tell from the path to the settings file" I still have to add "-fPIC" to the settings file's C compiler flags for the memory package to compile.

EDIT:

GHC: 8.0.1

Originally that line in settings looked like this:

("C compiler flags", "-fno-PIE -fno-stack-protector")

After my changes it looks likes this:

("C compiler flags", "-fno-PIE -fPIC -fno-stack-protector")
borsboom commented 7 years ago

The way GHC is installed on Ubuntu 16.10 etc. is by setting these environment variables before calling the ghc bindist's ./configure:

These are specified in stack-setup-2.yaml.

Does anyone here know whether these environment variables can be modified to do the right thing? You can experiment locally either by manually installing GHC from the bindist or by modifying a local copy of stack-setup-2.yaml and passing it into stack setup --stack-setup-yaml=stack-setup-2.yaml.

berdario commented 7 years ago

@denibertovic ¯\_(ツ)_/¯ I have

("C compiler flags", "-no-pie -fno-stack-protector"),

and it does the job

GildedHonour commented 7 years ago

I'm on Arch Linux:

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

error: sed: can't read /home/alex/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/settings: No such file or directory

$ stack --version
Version 1.3.2 x86_64

and

$ ls ~/.stack/programs/x86_64-linux/
ghc-7.10.3            ghc-8.0.1
ghc-7.10.3.installed  ghc-8.0.1.installed
ghc-7.10.3.tar.xz     ghc-8.0.1.tar.xz
nirvinm commented 7 years ago

None of the configuration hacks mentioned here works on Fedora 25. Using Stack version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5.

enolan commented 7 years ago

The PR that closed this issue should've fixed this - it changes the environment variables set when ./configure is run.

@nirvinm can you delete ~/.stack/programs, run stack setup and try again?

@GildedHonour if you have ghc-8.0.1 and not ghc-nopie-8.0.1 then either your problem is not PIE or Stack isn't detecting it for some reason. The logic is in Stack.Setup IIRC.

nirvinm commented 7 years ago

@enolan I tried deleting the ~/.stack/* directories and run stack setup again. But still getting the same linker error. Using GCC 6.3.1

UPDATE: I installed gmp-devel package on Fedora. It fixed the issue.

cblp commented 7 years ago

I successfully built network, memory and clock with nightly-2017-01-31/ghc-8.0.2 (x86_64-nopie)

armarti commented 7 years ago

On Ubuntu 16.10, I was finally able to get stack setup 7.10.3 to work by:

I'm sure this is overkill but I've battled this for two days so I've thrown everything I have at it.More than happy to provide any config info anyone might need.

$ stack --version Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0

ghost commented 7 years ago

Seems to have same linking problem for clock.

OS: 4.11.9-1-ARCH GHC: 8.0.2 Stack Version: 1.4.0

--  While building package clock-0.7.2 using:
      /home/mihai/.stack/setup-exe-cache/x86_64-linux-tinfo6-nopie/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/mihai/Development/qchas/.stack-work/logs/clock-0.7.2.log

    Configuring clock-0.7.2...
    Building clock-0.7.2...
    Preprocessing library clock-0.7.2...
    Clock.hsc:44:0: warning: "hsc_alignment" redefined
    In file included from .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/System/Clock_hsc_make.c:1:0:
    /home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/template-hsc.h:88:0: note: this is the location of the previous definition
     #define hsc_alignment(t...) \

    /usr/bin/ld: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/System/Clock_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-tinfo6-nopie/Cabal-1.24.2.0/build/System/Clock_hsc_make.o failed (exit code 1)
    command was: /usr/bin/gcc .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/System/Clock_hsc_make.o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/System/Clock_hsc_utils.o -o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/System/Clock_hsc_make -fno-PIE -fno-stack-protector -L/home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -Wl,-R,/home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -L/home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 -Wl,-R,/home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 -lgmp -L/home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 -Wl,-R,/home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 -L/home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/rts -Wl,-R,/home/mihai/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/rts -lm -lrt -ldl -lpthread

is there a fix?

Edit: Seems that the problem was fixed by installing ncurses5-compat-libs.

nd2s commented 7 years ago

@ardeleanasm I'm on stack 1.5.0 on Arch and reinstalling doesn't work.

ghost commented 7 years ago

@nd2s I don't have the problem anymore. I installed ncurses5-compat-libs, removed /home/user/.stack/ and reinstalled stack. hope it works!

nd2s commented 7 years ago

@ardeleanasm Installing ncurses5-compat-libs fixed it, didn't need to reinstall stack. Many thanks!

ghost commented 7 years ago

@nd2s you're welcome and I'm glad I could help you!

schoettl commented 7 years ago

I had the same problem since about 2 weeks. I'm on Arch Linux with stack 1.5.1 and GHC 7.10.3 (according to the build plan).

Finally, the @berdario's fix solved the problem for me.

My project is a @yesodweb Yesod app, so maybe it is related to position independent execution (PIE). I don't have hardening-wrapper installed. I tried a lot with -static, -fPIC, ... as suggested in similar problem reports.

There is a short FAQ entry on this problem, too.

NorfairKing commented 7 years ago

I'm having this problem now and installing ncurses5-compat-libs doesn't work, even after removing ~/.stack and re-installing stack.

EDIT: In my case I had to un-install ncurses5-compat-libs and install ncurses-full.

ZernovG commented 6 years ago

I've also had this problem on arch. As been said on wiki there are some troubles with dynamic and static link. So, basically, I tried to installed some libs depend on old base (<4.10) with brand new ghc, just from arch repo, and then ran into dependency hell with errors like described above. So what i've done

  1. Installed static linked stack from official site (dynamically on official arch repo)
  2. Installed ghc with stack --install-ghc
  3. Tried to install stylish-haskell with stack, failed to compile old-time with '-fPIC' error
  4. Manually extract it with 
    stack unpack old-time
cd old-time
stack init
stack build
  5. Found out that it need old base lib, so firstly tried to install ghc 7.10.3 with stack, but again the same error. Than i did the following 
    cd ~/.stack/programs/x86_64-linux
rm -rf ghc-tinfo6-nopie-7.10.3
tar xvfJ ghc-tinfo6-nopie-7.10.3.tar.xz
cd ghc-7.10.3 
./configure --with-hs-cpp-flags='-E -undef -traditional -fPIC -fno-PIE' --prefix=~/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-7.10.3
make install
cd ~/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-7.10.3/lib/ghc-7.10.3/
vi settings
  6. Changed C compiler flags to ("C compiler flags", "-fno-PIE -fPIC -fno-stack-protector")
  7. Than returned to old-time dir and rebuild it. (Do not forget to remove .stack-work)

That's it! Finally I managed to install stylish-haskell.

t3hmrman commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 https://github.com/commercialhaskell/stack/issues/2712#issuecomment-347702380 fixes the issue for me.

chrissound commented 6 years ago

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

borsboom commented 6 years ago

@chrissound, @drvink: This is being discussed in https://github.com/commercialhaskell/stack/issues/3518.