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

Benchmarks can no longer be built with Stack 1.6.1 #3630

Closed
mrkkrp opened this Issue Dec 7, 2017 · 16 comments

Comments

Projects
None yet
10 participants
@mrkkrp
Collaborator

mrkkrp commented Dec 7, 2017

I have a project, which has some benchmarks. Before upgrading to the latest Stack 1.6.1 I had no issues building and running the benchmarks, but now I'm getting the following:

stack bench mmark
mmark-0.0.1.1: unregistering (missing dependencies: criterion)
code-page-0.1.3: configure
code-page-0.1.3: build
Progress: 1/4
--  While building custom Setup.hs for package code-page-0.1.3 using:
      /home/mark/.stack/setup-exe-cache/x86_64-linux-tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.0.0.2_ghc-8.2.1 --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.0.2 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/mark/projects/programs/haskell/mmark/.stack-work/logs/code-page-0.1.3.log

    Configuring code-page-0.1.3...
    Preprocessing library for code-page-0.1.3..
    /usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.0.2/build/System/Win32/CodePage_hsc_make.o: requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
    /usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.0.2/build/System/Win32/CodePage_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-tinfo6-nopie/Cabal-2.0.0.2/build/System/Win32/CodePage_hsc_make.o failed (exit code 1)
    command was: /usr/bin/gcc .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.0.2/build/System/Win32/CodePage_hsc_make.o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.0.2/build/System/Win32/CodePage_hsc_utils.o -o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.0.2/build/System/Win32/CodePage_hsc_make -fuse-ld=gold -fno-PIE -fno-stack-protector -fuse-ld=gold -L/home/mark/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.1/lib/ghc-8.2.1/base-4.10.0.0 -Wl,-R,/home/mark/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.1/lib/ghc-8.2.1/base-4.10.0.0 -L/home/mark/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0 -Wl,-R,/home/mark/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0 -lgmp -L/home/mark/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.1/lib/ghc-8.2.1/ghc-prim-0.5.1.0 -Wl,-R,/home/mark/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.1/lib/ghc-8.2.1/ghc-prim-0.5.1.0 -L/home/mark/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.1/lib/ghc-8.2.1/rts -Wl,-R,/home/mark/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.1/lib/ghc-8.2.1/rts -lm -lrt -ldl -lpthread

Which apparently indicates an issue happening while building code-page-0.1.3, an error from the ld.gold linker. I'm wondering if it's an issue with Stack (because I'm using the same resolver and it worked before) or should I open an issue on the issue tracker of the code-page package.

I'm on Arch Linux.

$ stack --version
Version 1.6.1, Git revision f25811329bbc40b0c21053a8160c56f923e1201b (5435 commits) x86_64 hpack-0.20.0

Method of installation: originally unpacked the archive from https://www.stackage.org/stack/linux-x86_64 and copied the binary to ~/.local/bin/, upgraded by running

stack upgrade --git-repo=https://github.com/commercialhaskell/stack

To reproduce:

  • Clone the project I'm having issues with: https://github.com/mrkkrp/mmark
  • Run stack bench mmark.
  • Hopefully (or unfortunately) the issue will manifest itself.
@mrkkrp

This comment has been minimized.

Collaborator

mrkkrp commented Dec 7, 2017

I just downgraded to version 1.5.1 and it works again.

Will use that for now.

@scott-fleischman

This comment has been minimized.

Contributor

scott-fleischman commented Dec 8, 2017

Works on my machine. 🤷‍♂️

@lwm

This comment has been minimized.

Member

lwm commented Dec 9, 2017

Hmmm, seems like you have some nasty linker errors there?

    /usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.0.2/build/System/Win32/CodePage_hsc_make.o: requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
    /usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.0.2/build/System/Win32/CodePage_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

Does https://docs.haskellstack.org/en/stable/faq/#i-get-strange-ld-errors-about-recompiling-with-fpic help?

@mrkkrp

This comment has been minimized.

Collaborator

mrkkrp commented Dec 10, 2017

I have installed ncurses5-compat-libs from AUR as suggested, but the linking still fails with the same error. Compiling other stuff such as clock-0.7.2 also fails.

@passy

This comment has been minimized.

passy commented Dec 11, 2017

I haven't found a work-around for this one either. For me it's failing here:

/usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/System/Clock_hsc_make.o: requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
/usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/System/Clock_hsc_utils.o: requires dynamic R_X86_64_PC32 reloc against 'vprintf' which may overflow at runtime; recompile with -fPIC
@cocreature

This comment has been minimized.

Contributor

cocreature commented Dec 11, 2017

What worked for me is installing ncurses5-compat-libs and adding ghc-build: nopie to ~/.stack/config.yaml.

@lwm

This comment has been minimized.

Member

lwm commented Dec 11, 2017

Tough time on Arch right now! 👏

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 12, 2017

Hmm, so was there a regression here in stack 1.6.1 - is it some tradeoff where a different usecase got fixed but broke this one?

@mrkkrp

This comment has been minimized.

Collaborator

mrkkrp commented Dec 12, 2017

I don't know, that documentation page says that this issue is "reported to be non-deterministic in some cases". I'm sure though that on my system stack-1.5.1 works and stack-1.6.1 doesn't.

@matthew-piziak

This comment has been minimized.

matthew-piziak commented Dec 18, 2017

A few hours of library fiddling did not help me. Downgraded to stack-1.5.1 and that's working for now.

@flounders

This comment has been minimized.

flounders commented Dec 20, 2017

I just ran stack bench mmark which ran successfully with resolver lts-10.0. My .stack/config.yaml has ghc-build: tinfo6 which has resolved other recent Arch issues and only requires ncurses to work with no need for packages from AUR.

@mrkkrp

This comment has been minimized.

Collaborator

mrkkrp commented Dec 20, 2017

@flounders's solution works, I suggest it be mentioned in the docs.

@lwm

This comment has been minimized.

Member

lwm commented Dec 20, 2017

Glad that worked! Hmmm, but one recommended ghc-build: nopie and the other ghc-build: tinfo6? I'd like to make the documentation patch but not sure what should go there. Should it be in the FAQ - "I'm on Arch and my linker is blowing up"?

@mrkkrp

This comment has been minimized.

Collaborator

mrkkrp commented Dec 20, 2017

nopie works with ncurses5-compat-libs from AUR, tinfo6 works with ncurses from the official repositories.

@lwm lwm added this to the P2: Should milestone Dec 20, 2017

@Rufflewind

This comment has been minimized.

Rufflewind commented Dec 20, 2017

It seems Stack used to be able to find the correct ghc-build without manual intervention. What changed?

@borsboom

This comment has been minimized.

Contributor

borsboom commented Dec 24, 2017

This looks like another variant of #3518. Consolidating discussion there.

@borsboom borsboom closed this Dec 24, 2017

borsboom added a commit that referenced this issue Dec 30, 2017

borsboom added a commit that referenced this issue Jan 5, 2018

borsboom added a commit that referenced this issue Jan 5, 2018

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