@@ -540,21 +540,21 @@ in their `~/.bashrc` file to avoid the compiler error.
541## Using Stack together with Nix
541## Using Stack together with Nix
543−> -- While building package zlib-0.5.4.2 using:
543+ -- While building package zlib-0.5.4.2 using:
544−> /home/simons/.nix-profile/bin/runhaskell -package=Cabal-1.22.4.0 -clear-package-db -global-package-db -package-db=/home/simons/.stack/snapshots/x86_64-linux/nightly-2015-08-06/7.10.2/pkgdb/ /tmp/stack14237/Setup.hs --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ configure --user --package-db=clear --package-db=global --package-db=/home/simons/.stack/snapshots/x86_64-linux/nightly-2015-08-06/7.10.2/pkgdb/ --dependency=base=base-4.8.1.0-4f7206fd964c629946bb89db72c80011 --dependency=bytestring=bytestring-0.10.6.0-18c05887c1aaac7adb3350f6a4c6c8ed --libdir=/home/simons/.stack/snapshots/x86_64-linux/nightly-2015-08-06/7.10.2/lib --bindir=/home/simons/.stack/snapshots/x86_64-linux/nightly-2015-08-06/7.10.2/bin --datadir=/home/simons/.stack/snapshots/x86_64-linux/nightly-2015-08-06/7.10.2/share --docdir=/home/simons/.stack/snapshots/x86_64-linux/nightly-2015-08-06/7.10.2/doc/zlib-0.5.4.2 --htmldir=/home/simons/.stack/snapshots/x86_64-linux/nightly-2015-08-06/7.10.2/doc/zlib-0.5.4.2 --haddockdir=/home/simons/.stack/snapshots/x86_64-linux/nightly-2015-08-06/7.10.2/doc/zlib-0.5.4.2 --extra-lib-dirs=/nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8/lib
544+ runhaskell -package=Cabal-1.22.4.0 -clear-package-db [... lots of flags ...]
545−> Process exited with code: ExitFailure 1
545+ Process exited with code: ExitFailure 1
546−> Logs have been written to: /home/simons/src/stack-ide/.stack-work/logs/zlib-0.5.4.2.log
546+ Logs have been written to: /home/foo/src/stack-ide/.stack-work/logs/zlib-0.5.4.2.log
548−> Configuring zlib-0.5.4.2...
548+ Configuring zlib-0.5.4.2...
549−> Setup.hs: Missing dependency on a foreign library:
549+ Setup.hs: Missing dependency on a foreign library:
550−> * Missing (or bad) header file: zlib.h
550+ * Missing (or bad) header file: zlib.h
551−> This problem can usually be solved by installing the system package that
551+ This problem can usually be solved by installing the system package that
552−> provides this library (you may need the "-dev" version). If the library is
552+ provides this library (you may need the "-dev" version). If the library is
553−> already installed but in a non-standard location then you can use the flags
553+ already installed but in a non-standard location then you can use the flags
554−> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
554+ --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
555−> If the header file does exist, it may contain errors that are caught by the C
555+ If the header file does exist, it may contain errors that are caught by the C
556−> compiler at the preprocessing stage. In this case you can re-run configure
556+ compiler at the preprocessing stage. In this case you can re-run configure
557−> with the verbosity flag -v3 to see the error messages.
557+ with the verbosity flag -v3 to see the error messages.
559When you run the build inside of the nix-shell environment, the system
559When you run the build inside of the nix-shell environment, the system
560is configured to find libz.so without any special flags -- the compiler
560is configured to find libz.so without any special flags -- the compiler
@@ -562,44 +562,44 @@ and linker "just know" how to find it. Consequently, Cabal won't record
562any search paths for libz.so in the package description, which means
562any search paths for libz.so in the package description, which means
563that the package works fine inside of nix-shell, but once you leave the
563that the package works fine inside of nix-shell, but once you leave the
564shell the shared object can no longer be found. That issue is by no
564shell the shared object can no longer be found. That issue is by no
565−means specific to "stack": you'll have that problem with any other
565+means specific to Stack: you'll have that problem with any other
566Haskell package that's built inside of nix-shell but run outside of that
566Haskell package that's built inside of nix-shell but run outside of that
567environment.
567environment.
569−I suppose we could try to remedy the issue by wrapping "stack" or
569+I suppose we could try to remedy the issue by wrapping `stack` or
570−"cabal" with a script that tries to find those kind of implicit search
570+`cabal` with a script that tries to find those kind of implicit search
571paths and makes them explicit on the "cabal configure" command line. I
571paths and makes them explicit on the "cabal configure" command line. I
572don't think anyone is working on that subject yet, though, because the
572don't think anyone is working on that subject yet, though, because the
573problem doesn't seem so bad in practice.
573problem doesn't seem so bad in practice.
575You can remedy that issue in several ways. First of all, run
575You can remedy that issue in several ways. First of all, run
577− $ nix-build --no-out-link "<nixpkgs>" -A zlib
577+ $ nix-build --no-out-link "<nixpkgs>" -A zlib
578− /nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8
578+ /nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8
580to find out the store path of the system's zlib library. Now, you can
580to find out the store path of the system's zlib library. Now, you can
582− 1) add that path (plus a "/lib" suffix) to your $LD_LIBRARY_PATH
582+1) add that path (plus a "/lib" suffix) to your $LD_LIBRARY_PATH
583− environment variable to make sure your system linker finds libz.so
583+ environment variable to make sure your system linker finds libz.so
584− automatically. It's no pretty solution, but it will work.
584+ automatically. It's no pretty solution, but it will work.
586− 2) As a variant of (1), you can also install any number of system
586+2) As a variant of (1), you can also install any number of system
587− libraries into your user's profile (or some other profile) and point
587+ libraries into your user's profile (or some other profile) and point
588− $LD_LIBRARY_PATH to that profile instead, so that you don't have to
588+ $LD_LIBRARY_PATH to that profile instead, so that you don't have to
589− list dozens of those store paths all over the place.
589+ list dozens of those store paths all over the place.
591− 3) The solution I prefer is to call stack with an appropriate
591+3) The solution I prefer is to call stack with an appropriate
592− --extra-lib-dirs flag like so:
592+ --extra-lib-dirs flag like so:
594− $ stack --extra-lib-dirs=/nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8/lib build
594+ $ stack --extra-lib-dirs=/nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8/lib build
596− Typically, you'll need --extra-include-dirs as well. It's possible
596+ Typically, you'll need --extra-include-dirs as well. It's possible
597− to add those flag to the project's "stack.yaml" or your user's
597+ to add those flag to the project's "stack.yaml" or your user's
598− global "~/.stack/global/stack.yaml" file so that you don't have to
598+ global "~/.stack/global/stack.yaml" file so that you don't have to
599− specify them manually every time.
599+ specify them manually every time.
601− The same thing applies to "cabal configure", of course, if you're
601+ The same thing applies to `cabal configure`, of course, if you're
602− building with cabal-install instead of Stack.
602+ building with `cabal-install` instead of Stack.
605# Other resources
605# Other resources