Adding criterion to lts-9.5 causes failure to compile

[leshow]

General summary/comments (optional)

I created a new project with stack new randomContent simple it used lts-9.5 I added the bytestrings dependency to my cabal file, coded for a while, stack built fine. I wanted to benchmark my code so I added criterion as a dependency also.

Which causes this error:

>  ~/dev/haskell/haskell-programming-book/randomContent [master] ⚡ stack build
code-page-0.1.3: configure
code-page-0.1.3: build
cassava-0.4.5.1: configure
cassava-0.4.5.1: build
statistics-0.13.3.0: configure
statistics-0.13.3.0: build
cassava-0.4.5.1: copy/register
statistics-0.13.3.0: copy/register
Progress: 3/5
--  While building package code-page-0.1.3 using:
      /home/leshow/.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/leshow/dev/haskell/haskell-programming-book/randomContent/.stack-work/logs/code-page-0.1.3.log

    Configuring code-page-0.1.3...
    Building code-page-0.1.3...
    Preprocessing library code-page-0.1.3...
    /usr/bin/ld: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/System/Win32/CodePage_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/Win32/CodePage_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/Win32/CodePage_hsc_make.o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/System/Win32/CodePage_hsc_utils.o -o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/System/Win32/CodePage_hsc_make -fno-PIE -fno-stack-protector -L/home/leshow/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -Wl,-R,/home/leshow/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -L/home/leshow/.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/leshow/.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/leshow/.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/leshow/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 -L/home/leshow/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/rts -Wl,-R,/home/leshow/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/rts -lm -lrt -ldl -lpthread

Steps to reproduce

For example:

stack new randomContent simple
# add , bytestring, criterion to build-depends
# import Criterion.Main (in my case in another module)
stack build

Include any .yaml configuration if relevant.

name:                randomContent
version:             0.1.0.0
-- synopsis:
-- description:
homepage:            https://github.com/leshow/randomContent#readme
license:             BSD3
license-file:        LICENSE
author:              Evan Cameron
maintainer:          cameron.evan@gmail.com
copyright:           MIT
category:            none
build-type:          Simple
cabal-version:       >=1.10
extra-source-files:  README.md

executable randomContent
  hs-source-dirs:      src
  main-is:             Main.hs
  default-language:    Haskell2010
  build-depends:       base >= 4.7 && < 5
                     , bytestring
                     , criterion

stack.yaml is teh default provided by stack new

Expected

I expected the dependency to be resolved without issue

Actual

adding criterion makes the build fail with a linker error,

Stack version

>  ~/dev/haskell/haskell-programming-book/randomContent [master] ⚡ stack --version
Version 1.5.1 x86_64

Method of installation

Installed from arch regular repos, not the AUR. System is up to date.

##Additional

I went back to try and rebuild packages with criterion in them that previously built just fine, I was unable to build them. They all fail on code-page with the -fPIC error

[mgsloan]

It builds fine for me.

Weird thing is that since you're not on windows, the module linking is failing on should be completely empty.

May be worth while to blow away ~/.stack/snapshots and ~/.stack/precompiled and try building again. Usually not necessary / helpful, but if something went wrong something could be corrupted..

[leshow]

You tried on windows? I'm not surprised you didn't see the same result. For what it's worth, I did try multiple resolvers, some of which I had no local snapshots version. I tried 9.2, 9.0, 8.5, 8.2, the version of code-log was all different in the output but otherwise the build failure was the same. I looked through the issues and saw other arch users have had linker issues in the past, some recommended installing libncurses5 compat package. I have this package installed already, I tried reinstalling it also to no avail.

[mgsloan]

No, I tried on linux. Perhaps arch's linker is atypically old or atypically new. I'm using ld version 2.26.1 . We should probably default to the gold linker - #3128 #2938 - but that hasn't been implemented yet.

One possible hack might be to add a directory to the front of your PATH which has a symbolic link to the gold linker, renaming it to ld... Not a very nice hack, but could work

[leshow]

If anything it would be 'atypically new'. Arch is known for bleeding edge packages. I can check what version when I'm home.

…

On 22 September 2017 at 13:17, Michael Sloan ***@***.***> wrote: No, I tried on linux. Perhaps arch's linker is atypically old or atypically new. I'm using ld version 2.26.1 . We should probably default to the gold linker - #3128 <#3128> #2938 <#2938> - but that hasn't been implemented yet. One possible hack might be to add a directory to the front of your PATH which has a symbolic link to the gold linker, renaming it to ld... Not a very nice hack, but could work — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3448 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABE3biIKsjbUVZvCCXW88XhKiNDLetanks5sk-uzgaJpZM4PgJwf> .

-- Evan Cameron

[leshow]

>  ~  uname -ar
Linux leshowbox 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43 UTC 2017 x86_64 GNU/Linux
>  ~  ld --version
GNU ld (GNU Binutils) 2.29
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

My linker version is indeed much newer.

[aiya000]

I maybe meeting the same problem at now 😭
I built the existed haskell-stack project,
it uses lts-9.2.

>>> uname -ar
Linux BlueAloha 4.6.0-1-surfacepro3 #1 SMP PREEMPT Wed Apr 5 14:12:33 JST 2017 x86_64 GNU/Linux

>>> ld --version
GNU ld (GNU Binutils) 2.29
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

>>> stack --version | head -1
Version 1.5.1 x86_64

I updated haskell-stack at a few days ago,
and met this problem || 🐕

[aiya000]

I fixed this problem on my environment !

$ yaourt -Rns libtinfo
$ yaourt -S ncurses5-compat-libs
$ rm -rf ~/.stack .stack-work

$ cd /usr/lib
$ sudo mv libncurses.so{,.bak}
$ sudo ln -s libncursesw.so.6.0 libncurses.so

(the last half is this workaround)

After this, stack build is passed 👍

[decentral1se]

Nice @aiya000 👍

@leshow, please let us know if that solution works for you.

[leshow]

I'll try it in a few hours, sure.

[zpalmtree]

I had the same issue with network, old-time, and clock, @aiya000's solution fixed it for me, thanks!

[leshow]

@aiya000 why do you need to remove libtinfo? Any reason for that?

also, it kinda sucks manually linking packages in /lib. I'm sure pacman or some other library is going to complain later.

[leshow]

Seems like just removing libtinfo and re-installing ncurses5-compat-libs has gotten the project to build. I must have recently installed libtinfo which would explain why everything was building before, and suddenly stopped working.

I will close this issue.