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

Benchmarks can no longer be built with Stack 1.6.1 #3630

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

Benchmarks can no longer be built with Stack 1.6.1 #3630

mrkkrp opened this issue Dec 7, 2017 · 16 comments

Comments

@mrkkrp
Copy link
Collaborator

@mrkkrp 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
Copy link
Collaborator Author

@mrkkrp mrkkrp commented Dec 7, 2017

I just downgraded to version 1.5.1 and it works again.

Will use that for now.

@scott-fleischman
Copy link
Contributor

@scott-fleischman scott-fleischman commented Dec 8, 2017

Works on my machine. 🤷‍♂️

@decentral1se
Copy link
Member

@decentral1se decentral1se 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
Copy link
Collaborator Author

@mrkkrp 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
Copy link

@passy 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
Copy link
Contributor

@cocreature cocreature commented Dec 11, 2017

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

@decentral1se
Copy link
Member

@decentral1se decentral1se commented Dec 11, 2017

Tough time on Arch right now! 👏

@mgsloan
Copy link
Contributor

@mgsloan 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
Copy link
Collaborator Author

@mrkkrp 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
Copy link

@matthew-piziak 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
Copy link

@flounders 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
Copy link
Collaborator Author

@mrkkrp mrkkrp commented Dec 20, 2017

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

@decentral1se
Copy link
Member

@decentral1se decentral1se 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
Copy link
Collaborator Author

@mrkkrp mrkkrp commented Dec 20, 2017

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

@Rufflewind
Copy link
Contributor

@Rufflewind Rufflewind commented Dec 20, 2017

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

@borsboom
Copy link
Contributor

@borsboom 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants