Question: custom GHC path in stack.yaml?

[rpglover64]

Is there a way to tell stack to use GHC at a specific location for a project? I don't want to put it on the path every time I run stack for that project.

[snoyberg]

No, there's no such functionality right now. The primary concern I'd have is that it would make your project tied to a specific machine's configuration.

[rpglover64]

Makes sense. It would be bad practice for release, but I think it's still useful for development.

With cabal, I could put it in a cabal.config file at the with-compiler field.

It also occurs to me that if I want to use a GHC installed at a non-standard location for all my projects, I could symlink it to where stack searches for its personal copies if I knew the exact naming scheme.

My specific usecase is that I want to use a patched 7.10.2 to build stackage nightlies and eventually LTS.

[snoyberg]

Got reminded on Reddit about this: I should have pinged this issue when #798 got merged to master, which will allow you to do something like:

extra-path:
- /path/to/ghc/bin

[rpglover64]

Awesome. I think that solves my problem.

[nh2]

I had to do this to make stack pick up my custom ghc I built from the ghc source dir:

First in my ghc source dir, cd inplace/bin && ln -s ghc-stage2 ghc to make sure my ghc executable is available as ghc.

Then in stack.yaml of the project I want to compile with my custom ghc:

extra-path:
- /path/to/ghc/checkout/inplace/bin

system-ghc: true
skip-ghc-check: true

Note: This is only for when you're hacking on GHC incrementally. If you just want to use a different bindist, see How to use different ghc builds with stack?.

[osa1]

Is there a better way to do this these days or is the comment above still the best option?

[mgsloan]

@osa1 I believe the above comment is still the best option. A more general solution to this sort of thing is tracked by #2369

[jberryman]

Trying @nh2 's technique and getting linker error partway through a big cabal build

2019-02-26 11:25:36.340359: [info] lens-4.17: configure (lib)
2019-02-26 11:25:36.341619: [debug] Run process within /home/me/Code/BOLT-experiments/lens-4.17/: /home/me/Code/NOT_MY_CODE/ghc/inplace/bin/ghc-stage2 --make -odir /home/me/Code/BOLT-experiments/lens-4.17/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup -hidir /home/me/Code/BOLT-experiments/lens-4.17/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup -i -i. -clear-package-db -global-package-db -package-db=/home/me/.stack/snapshots/x86_64-linux/lts-13.5/8.6.3/pkgdb -package-db=/home/me/Code/BOLT-experiments/.stack-work/install/x86_64-linux/lts-13.5/8.6.3/pkgdb -hide-all-packages -package-id=Cabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D -package-id=base-4.12.0.0 -package-id=cabal-doctest-1.0.6-86ieqb3MUgY7IBnRw4OXav -package-id=filepath-1.4.2.1 -optP-include -optP/home/me/Code/BOLT-experiments/lens-4.17/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup/setup_macros.h /home/me/Code/BOLT-experiments/lens-4.17/Setup.lhs /home/me/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /home/me/Code/BOLT-experiments/lens-4.17/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup/setup -threaded
2019-02-26 11:25:36.487033: [info] [1 of 2] Compiling Main             ( /home/me/Code/BOLT-experiments/lens-4.17/Setup.lhs, /home/me/Code/BOLT-experiments/lens-4.17/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup/Main.o )
2019-02-26 11:25:36.592745: [info] [2 of 2] Compiling StackSetupShim   ( /home/me/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /home/me/Code/BOLT-experiments/lens-4.17/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup/StackSetupShim.o )
2019-02-26 11:25:36.744372: [info] Linking /home/me/Code/BOLT-experiments/lens-4.17/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup/setup ...
2019-02-26 11:25:38.016434: [warn] /home/me/.stack/snapshots/x86_64-linux/lts-13.5/8.6.3/lib/x86_64-linux-ghc-8.6.3/Cabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D/libHSCabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D.a(Configure.o)(.text+0xa379): error: undefined reference to 'base_GHCziIOziException_zdfExceptionIOException4_closure'
2019-02-26 11:25:38.016565: [warn] /home/me/.stack/snapshots/x86_64-linux/lts-13.5/8.6.3/lib/x86_64-linux-ghc-8.6.3/Cabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D/libHSCabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D.a(Configure.o)(.text+0xa919): error: undefined reference to 'base_GHCziIOziException_zdfExceptionIOException4_closure'
2019-02-26 11:25:38.016622: [warn] /home/me/.stack/snapshots/x86_64-linux/lts-13.5/8.6.3/lib/x86_64-linux-ghc-8.6.3/Cabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D/libHSCabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D.a(Configure.o)(.text+0x2d1e1): error: undefined reference to 'base_GHCziIOziException_zdfExceptionIOException4_closure'
2019-02-26 11:25:38.016678: [warn] /home/me/.stack/snapshots/x86_64-linux/lts-13.5/8.6.3/lib/x86_64-linux-ghc-8.6.3/Cabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D/libHSCabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D.a(Configure.o)(.data+0x5468): error: undefined reference to 'base_GHCziIOziException_zdfExceptionIOException4_closure'
2019-02-26 11:25:38.017922: [warn] collect2: error: ld returned 1 exit status
2019-02-26 11:25:38.018562: [warn] `gcc' failed in phase `Linker'. (Exit code: 1)

[nh2]

@jberryman Can you clean and rebuild just to make sure you aren't suffering from .o file corruption?

Also, which of the two techniques I mentioned are you using the one for

hacking on GHC incrementally

or the other one?

[jberryman]

@nh2 sorry, yes "hacking on ghc". Yeah I've tried clean --full, as well as setting extra-lib-dirs to inplace/lib/.

[nh2]

@jberryman Hmm, then I'm not sure, especially given that you apparently have a missing symbol in something as basic as GHC.Exception, but it pops up only as late as lens.

[jberryman]

Thanks it's a multiproject stack repo with some random libraries stack unpack-ed into it (including lens). I edited my original post above with better output.

I wonder if you can repro with stack unpack lens-4.17 && stack build lens.

It seems to be related to lens's use of a custom-setup section in the lens cabal file. If I remove that section I can build the library successfully. EDIT: although now I'm getting a similar error during configure on shakespeare which uses a build-type: Simple...

Appreciate the tip. I'm going to move on for now, and don't want to clutter this ticket anymore.

EDIT2: I wonder if it has something to do with the ordering of package dbs (inplace ghc's are last):

stack/src/Stack/GhcPkg.hs

Line 181 in 3bb2a02

mkGhcPackagePath :: Bool -> Path Abs Dir -> Path Abs Dir -> [Path Abs Dir] -> Path Abs Dir -> Text

[nh2]

@jberryman I care about this workflow working, so I'd be happy to help with it.

But can you make me some detail instructions on what to do?

I wonder if you can repro with stack unpack lens-4.17 && stack build lens.

With what exact stack.yaml?

[chrisdone]

@nh2 This advice no longer works on stack 2:

resolver: lts-12.12
compiler: ghc-8.4.3
system-ghc: true
skip-ghc-check: true
extra-path:
- /home/chris/.stack/programs/x86_64-linux/ghc-8.4.3/bin-prana

And

$ /home/chris/.stack/programs/x86_64-linux/ghc-8.4.3/bin-prana/ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.3
$ stack exec which ghc
/home/chris/.stack/programs/x86_64-linux/ghc-8.4.3/bin/ghc
$ stack path --bin-path
/home/chris/.stack/snapshots/x86_64-linux/abcd5dc684e06ad4bd818ffac453427d55dd5fc0fb0de8a8e6f88fe63287c551/8.4.3/bin:/home/chris/.stack/compiler-tools/x86_64-linux/ghc-8.4.3/bin:/home/chris/.stack/programs/x86_64-linux/ghc-8.4.3/bin:/home/chris/.stack/programs/x86_64-linux/ghc-8.4.3/bin-prana:/usr/local/lib/nodejs/node-v12.2.0-linux-x64/bin/:/home/chris/.local/bin:/home/chris/.cargo/bin:/usr/sbin:/usr/local/bin:/usr/bin:/bin:/sbin:/usr/local/bin:/Users/chris/.local/bin/:/Users/chris/.cargo/bin/

stack --version
Version 2.2.0, Git revision aa3a5f2573ffe8791f63e621447c9084d5aa0ba1 (7622 commits) PRE-RELEASE x86_64 hpack-0.31.1

[chrisdone]

An alternative approach that seems to work is:

cp $(stack exec which prana-ghc) $(stack path --compiler-tools-bin)/ghc

resolver: lts-12.12
compiler: ghc-8.4.3

We don't need

resolver: lts-12.12
compiler: ghc-8.4.3

because compiler-tools overrides anything else.

Because that path appears higher up in the PATH list:

/home/chris/.stack/snapshots/x86_64-linux/abcd5dc684e06ad4bd818ffac453427d55dd5fc0fb0de8a8e6f88fe63287c551/8.4.3/bin
/home/chris/.stack/compiler-tools/x86_64-linux/ghc-8.4.3/bin
/home/chris/.stack/programs/x86_64-linux/ghc-8.4.3/bin
/usr/local/lib/nodejs/node-v12.2.0-linux-x64/bin/
/home/chris/.local/bin
/home/chris/.cargo/bin
/usr/sbin
/usr/local/bin
/usr/bin
/bin
/sbin
/usr/local/bin
/Users/chris/.local/bin/
/Users/chris/.cargo/bin/

I think you need a stack clean for it to take effect.

[chrisdone]

Here's a full log of my results:

chris@precision:~/Work/chrisdone/prana/test-project$ stack clean && stack build
test-project-0: unregistering (local file changes: Test.hs test-project.cabal)
test-project> configure (lib)
Configuring test-project-0...
test-project> build (lib)
Preprocessing library for test-project-0..
Building library for test-project-0..
[1 of 1] Compiling Test
ignoring (possibly broken) abi-depends field for packages
test-project> copy/register
Installing library in /home/chris/Work/chrisdone/prana/test-project/.stack-work/install/x86_64-linux/abcd5dc684e06ad4bd818ffac453427d55dd5fc0fb0de8a8e6f88fe63287c551/8.4.3/lib/x86_64-linux-ghc-8.4.3/test-project-0-LQoencmL5QdtAQo3osupp
Registering library for test-project-0..

Move the bin to the compiler-tools dir:

chris@precision:~/Work/chrisdone/prana/test-project$ mv bin /home/chris/.stack/compiler-tools/x86_64-linux/ghc-8.4.3/bin

Then it works:

chris@precision:~/Work/chrisdone/prana/test-project$ stack clean && stack build
test-project-0: unregistering (local file changes: Test.hs test-project.cabal)
test-project> configure (lib)
Configuring test-project-0...
test-project> build (lib)
Preprocessing library for test-project-0..
Building library for test-project-0..
[1 of 1] Compiling Test
[1 of 1] Compiling Test
[1 of 1] Converting Test
Updating index ... 
Writing library test-project ...
Wrote library to /home/chris/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/prana/packages/test-project.prana
ignoring (possibly broken) abi-depends field for packages
test-project> copy/register
Installing library in /home/chris/Work/chrisdone/prana/test-project/.stack-work/install/x86_64-linux/abcd5dc684e06ad4bd818ffac453427d55dd5fc0fb0de8a8e6f88fe63287c551/8.4.3/lib/x86_64-linux-ghc-8.4.3/test-project-0-LQoencmL5QdtAQo3osupp
Registering library for test-project-0..
chris@precision:~/Work/chrisdone/prana/test-project$