Package Hoogle-5.0.1 and wreq-0.4.1.0 fail to build during install on Ubuntu 16.04

[josiah14]

--- Installing helper binaries...
Progress: 2/3
--  While building package wreq-0.4.1.0 using:
      /tmp/stack21091/wreq-0.4.1.0/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/setup/setup --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/josiah/.stack/global-project/.stack-work/logs/wreq-0.4.1.0.log

    [1 of 2] Compiling Main             ( /tmp/stack21091/wreq-0.4.1.0/Setup.hs, /tmp/stack21091/wreq-0.4.1.0/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/setup/Main.o )

    /tmp/stack21091/wreq-0.4.1.0/Setup.hs:63:15: warning: [-Wdeprecations]
        In the use of type constructor or class ‘InstalledPackageId’
        (imported from Distribution.Package):
        Deprecated: "Use UnitId instead"
    [2 of 2] Compiling StackSetupShim   ( /home/josiah/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack21091/wreq-0.4.1.0/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/setup/StackSetupShim.o )
    Linking /tmp/stack21091/wreq-0.4.1.0/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/setup/setup ...
    Configuring wreq-0.4.1.0...
    Building wreq-0.4.1.0...
    Preprocessing library wreq-0.4.1.0...
    [ 1 of 15] Compiling Network.Wreq.Lens.Machinery ( Network/Wreq/Lens/Machinery.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/Wreq/Lens/Machinery.o )
    [ 2 of 15] Compiling Paths_wreq       ( .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen/Paths_wreq.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Paths_wreq.o )
    [ 3 of 15] Compiling Network.Wreq.Internal.OAuth1 ( Network/Wreq/Internal/OAuth1.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/Wreq/Internal/OAuth1.o )
    [ 4 of 15] Compiling Network.Wreq.Cache.Store ( Network/Wreq/Cache/Store.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/Wreq/Cache/Store.o )
    [ 5 of 15] Compiling Network.Wreq.Internal.Types ( Network/Wreq/Internal/Types.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/Wreq/Internal/Types.o )
    [ 6 of 15] Compiling Network.Wreq.Internal.Lens ( Network/Wreq/Internal/Lens.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/Wreq/Internal/Lens.o )
    <command line>: can't load .so/.DLL for: /home/josiah/.stack/snapshots/x86_64-linux/lts-7.13/8.0.1/lib/x86_64-linux-ghc-8.0.1/random-1.1-54KmMHXjttlERYcr1mvsAe/libHSrandom-1.1-54KmMHXjttlERYcr1mvsAe-ghc8.0.1.so (/home/josiah/.stack/snapshots/x86_64-linux/lts-7.13/8.0.1/lib/x86_64-linux-ghc-8.0.1/random-1.1-54KmMHXjttlERYcr1mvsAe/libHSrandom-1.1-54KmMHXjttlERYcr1mvsAe-ghc8.0.1.so: undefined symbol: timezm1zi6zi0zi1_DataziTimeziClockziCTimespec_getCTimespec1_closure)

--  While building package hoogle-5.0.1 using:
      /home/josiah/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.0.0_ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/josiah/.stack/global-project/.stack-work/logs/hoogle-5.0.1.log

    Configuring hoogle-5.0.1...
    Building hoogle-5.0.1...
    Preprocessing library hoogle-5.0.1...
    [ 1 of 28] Compiling General.IString  ( src/General/IString.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/General/IString.o )
    [ 2 of 28] Compiling General.Str      ( src/General/Str.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/General/Str.o )
    [ 3 of 28] Compiling General.Conduit  ( src/General/Conduit.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/General/Conduit.o )
    [ 4 of 28] Compiling General.Template ( src/General/Template.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/General/Template.o )
    [ 5 of 28] Compiling Input.Set        ( src/Input/Set.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Input/Set.o )
    [ 6 of 28] Compiling Paths_hoogle     ( .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen/Paths_hoogle.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Paths_hoogle.o )
    [ 7 of 28] Compiling Input.Settings   ( src/Input/Settings.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Input/Settings.o )
    <command line>: can't load .so/.DLL for: /home/josiah/.stack/snapshots/x86_64-linux/lts-7.13/8.0.1/lib/x86_64-linux-ghc-8.0.1/random-1.1-54KmMHXjttlERYcr1mvsAe/libHSrandom-1.1-54KmMHXjttlERYcr1mvsAe-ghc8.0.1.so (/home/josiah/.stack/snapshots/x86_64-linux/lts-7.13/8.0.1/lib/x86_64-linux-ghc-8.0.1/random-1.1-54KmMHXjttlERYcr1mvsAe/libHSrandom-1.1-54KmMHXjttlERYcr1mvsAe-ghc8.0.1.so: undefined symbol: timezm1zi6zi0zi1_DataziTimeziClockziCTimespec_getCTimespec1_closure)

[josiah14]

Current workaround I discovered (just now) is to use LTS-6.17 (GHC 7.10.3) instead of LTS-7.13 (GHC 8.0.1). I did this by editing my global stack config at ~/.stack/global-project/stack.yaml

[begriffs]

Yeah it honors the LTS of the global config. I guess it just won't work for certain LTS versions, although I wonder if the hard-coding of some versions in our install list is still necessary...

[josiah14]

My personal philosophy about software is that it should "Just work". If you aren't going to support all LTS versions, then my vote would be to build the IDE binaries in a Stack/Cabal sandbox which uses a supported LTS. As a developer, I don't want my time to be spent troubleshooting why my IDE isn't installing - I just want to run the installer and start using it to work on projects I'm either being paid to deliver on within a specific timeline or that I'm pursuing for personal development as a hobby.

My hesitation with not supporting all LTS versions, however, is that, since this is meant to be an IDE, and not merely an app, it might not play nicely with Haskell projects build using unsupported LTS versions. If GHC-8.0.1 is not supported, how will ghc-mod break in my IDE for projects I create using GHC-8.0.1? Will I lose all of my ability to get type information on sub-expressions within my functions? Will it use the wrong ghc-mod and show me false type errors, instead? Will I lose all ability to compile the code from my editor, or will it compile with the wrong GHC and result in unpredictable behavior (compiling code that wouldn't compile, or not compiling code that would compile, under the correct GHC)? Lose CTags functionality? Lose Hoogle? I'm quickly reducing my IDE to a standard Text-editor. I might as well just install vanilla Vim with nice Syntax highlighting and call it a day.

For background, I came to this project because my normal editor, Spacemacs, hasn't proven well suited for me for Haskell development. If some module in the Haskell layer isn't working right, it pops-up a new split full of error messages every time I save a Haskell file in it - it was too verbose and invasive to be productive in. I came this project because, although it wasn't working properly, it still got out of my way and let me do my work, even when all of the features/modules weren't working perfectly. BUT - it would have been better had it been constructed in a way that enabled it to fully install automatically without errors, regardless of what my OS environment was like.

Let me end this by saying, I believe this is good work and I'm glad you created this project because when things DO fail, it tends to manage to still stay out of my way and provide me with the barebones core-editor functionality. I hope my feedback is constructive and not too abrasive.

[begriffs]

Totally understand. You're not abrasive at all; you make good points, and I appreciate the bug report. You correctly pointed out that it doesn't work on a more recent LTS version which is a problem because that is most likely what people will be using.

We could pin the LTS used to install the helper binaries, or make it work with all recent LTS versions. The advantage of the former is that things are known to work and keep working. The disadvantage, as you pointed out, is that ghc-mod built for an older version of the cabal library fails to work on new projects with newer cabal. A hybrid approach is pinning the LTS, but periodically trying to upgrade it and verifying that the install works.

The most flexible approach, of course, is making it work with all LTS versions. It makes sense to try to get to the bottom of the build failure you discovered. I'd love your help here to experiment with the install script and see if there's a change that will fix things. (I don't have time to investigate myself in the immediate future because I'm trying to iron out the last few issues on an overdue release of another project.)

[josiah14]

My time is also limited, but if I can find a spare moment, I'll have a look into it.

[begriffs]

(Ping, in case you're still interested)