@@ -1,633 +0,0 @@
1−---
2−title: User's Guide for Haskell in Nixpkgs
3−author: Peter Simons
4−date: 2015-06-01
5−---
6−
7−# How to install Haskell packages
8−
9−Nixpkgs distributes build instructions for all Haskell packages registered on
10−[Hackage](http://hackage.haskell.org/), but strangely enough normal Nix package
11−lookups don't seem to discover any of them:
12−
13− $ nix-env -qa cabal-install
14− error: selector ‘cabal-install’ matches no derivations
15−
16− $ nix-env -i ghc
17− error: selector ‘ghc’ matches no derivations
18−
19−The Haskell package set is not registered in the top-level namespace because it
20−is *huge*. If all Haskell packages were visible to these commands, then
21−name-based search/install operations would be much slower than they are now. We
22−avoided that by keeping all Haskell-related packages in a separate attribute
23−set called `haskellPackages`, which the following command will list:
24−
25− $ nix-env -f "<nixpkgs>" -qaP -A haskellPackages
26− haskellPackages.a50 a50-0.5
27− haskellPackages.abacate haskell-abacate-0.0.0.0
28− haskellPackages.abcBridge haskell-abcBridge-0.12
29− haskellPackages.afv afv-0.1.1
30− haskellPackages.alex alex-3.1.4
31− haskellPackages.Allure Allure-0.4.101.1
32− haskellPackages.alms alms-0.6.7
33− [... some 8000 entries omitted ...]
34−
35−To install any of those packages into your profile, refer to them by their
36−attribute path (first column):
37−
38− $ nix-env -f "<nixpkgs>" -iA haskellPackages.Allure ...
39−
40−The attribute path of any Haskell packages corresponds to the name of that
41−particular package on Hackage: the package `cabal-install` has the attribute
42−`haskellPackages.cabal-install`, and so on. (Actually, this convention causes
43−trouble with packages like `3dmodels` and `4Blocks`, because these names are
44−invalid identifiers in the Nix language. The issue of how to deal with these
45−rare corner cases is currently unresolved.)
46−
47−Haskell packages who's Nix name (second column) begins with a `haskell-` prefix
48−are packages that provide a library whereas packages without that prefix
49−provide just executables. Libraries may provide executables too, though: the
50−package `haskell-pandoc`, for example, installs both a library and an
51−application. You can install and use Haskell executables just like any other
52−program in Nixpkgs, but using Haskell libraries for development is a bit
53−trickier and we'll address that subject in great detail in section [How to
54−create a development environment].
55−
56−Attribute paths are deterministic inside of Nixpkgs, but the path necessary to
57−reach Nixpkgs varies from system to system. We dodged that problem by giving
58−`nix-env` an explicit `-f "<nixpkgs>"` parameter, but if you call `nix-env`
59−without that flag, then chances are the invocation fails:
60−
61− $ nix-env -iA haskellPackages.cabal-install
62− error: attribute ‘haskellPackages’ in selection path
63− ‘haskellPackages.cabal-install’ not found
64−
65−On NixOS, for example, Nixpkgs does *not* exist in the top-level namespace by
66−default. To figure out the proper attribute path, it's easiest to query for the
67−path of a well-known Nixpkgs package, i.e.:
68−
69− $ nix-env -qaP coreutils
70− nixos.pkgs.coreutils coreutils-8.23
71−
72−If your system responds like that (most NixOS installatios will), then the
73−attribute path to `haskellPackages` is `nixos.pkgs.haskellPackages`. Thus, if
74−you want to use `nix-env` without giving an explicit `-f` flag, then that's the
75−way to do it:
76−
77− $ nix-env -qaP -A nixos.pkgs.haskellPackages
78− $ nix-env -iA nixos.pkgs.haskellPackages.cabal-install
79−
80−Our current default compiler is GHC 7.10.x and the `haskellPackages` set
81−contains packages built with that particular version. Nixpkgs contains the
82−latest major release of every GHC since 6.10.4, however, and there is a whole
83−family of package sets available that defines Hackage packages built with each
84−of those compilers, too:
85−
86− $ nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc6123
87− $ nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc763
88−
89−The name `haskellPackages` is really just a synonym for
90−`haskell.packages.ghc7101`, because we prefer that package set internally and
91−recommend it to our users as their default choice, but ultimately you are free
92−to compile your Haskell packages with any GHC version you please. The following
93−command displays the complete list of available compilers:
94−
95− $ nix-env -f "<nixpkgs>" -qaP -A haskell.compiler
96− haskell.compiler.ghc6104 ghc-6.10.4
97− haskell.compiler.ghc6123 ghc-6.12.3
98− haskell.compiler.ghc704 ghc-7.0.4
99− haskell.compiler.ghc722 ghc-7.2.2
100− haskell.compiler.ghc742 ghc-7.4.2
101− haskell.compiler.ghc763 ghc-7.6.3
102− haskell.compiler.ghc784 ghc-7.8.4
103− haskell.compiler.ghc7101 ghc-7.10.1
104− haskell.compiler.ghcHEAD ghc-7.11.20150402
105− haskell.compiler.ghcjs ghcjs-0.1.0
106− haskell.compiler.jhc jhc-0.8.2
107− haskell.compiler.uhc uhc-1.1.9.0
108−
109−We have no package sets for `jhc` or `uhc` yet, unfortunately, but for every
110−version of GHC listed above, there exists a package set based on that compiler.
111−Also, the attributes `haskell.compiler.ghcXYC` and
112−`haskell.packages.ghcXYC.ghc` are synonymous for the sake of convenience.
113−
114−# How to create a development environment
115−
116−## How to install a compiler
117−
118−A simple development environment consists of a Haskell compiler and the tool
119−`cabal-install`, and we saw in section [How to install Haskell packages] how
120−you can install those programs into your user profile:
121−
122− $ nix-env -f "<nixpkgs>" -iA haskellPackages.ghc haskellPackages.cabal-install
123−
124−Instead of the default package set `haskellPackages`, you can also use the more
125−precise name `haskell.compiler.ghc7101`, which has the advantage that it refers
126−to the same GHC version regardless of what Nixpkgs considers "default" at any
127−given time.
128−
129−Once you've made those tools available in `$PATH`, it's possible to build
130−Hackage packages the same way people without access to Nix do it all the time:
131−
132− $ cabal get lens-4.11 && cd lens-4.11
133− $ cabal install -j --dependencies-only
134− $ cabal configure
135− $ cabal build
136−
137−If you enjoy working with Cabal sandboxes, then that's entirely possible too:
138−just execute the command
139−
140− $ cabal sandbox init
141−
142−before installing the required dependencies.
143−
144−The `nix-shell` utility makes it easy to switch to a different compiler
145−version; just enter the Nix shell environment with the command
146−
147− $ nix-shell -p haskell.compiler.ghc784
148−
149−to bring GHC 7.8.4 into `$PATH`. Re-running `cabal configure` switches your
150−build to use that compiler instead. If you're working on a project that doesn't
151−depend on any additional system libraries outside of GHC, then it's sufficient
152−even to run the `cabal configure` command inside of the shell:
153−
154− $ nix-shell -p haskell.compiler.ghc784 --command "cabal configure"
155−
156−Afterwards, all other commands like `cabal build` work just fine in any shell
157−environment, because the configure phase recorded the absolute paths to all
158−required tools like GHC in its build configuration inside of the `dist/`
159−directory. Please note, however, that `nix-collect-garbage` can break such an
160−environment because the Nix store paths created by `nix-shell` aren't "alive"
161−anymore once `nix-shell` has terminated. If you find that your Haskell builds
162−no longer work after garbage collection, then you'll have to re-run `cabal
163−configure` inside of a new `nix-shell` environment.
164−
165−## How to install a compiler with libraries
166−
167−GHC expects to find all installed libraries inside of its own `lib` directory.
168−This approach works fine on traditional Unix systems, but it doesn't work for
169−Nix, because GHC's store path is immutable once it's built. We cannot install
170−additional libraries into that location. As a consequence, our copies of GHC
171−don't know any packages except their own core libraries, like `base`,
172−`containers`, `Cabal`, etc.
173−
174−We can register additional libraries to GHC, however, using a special build
175−function called `ghcWithPackages`. That function expects one argument: a
176−function that maps from an attribute set of Haskell packages to a list of
177−packages, which determines the libraries known to that particular version of
178−GHC. For example, the Nix expression `ghcWithPackages (pkgs: [pkgs.mtl])`
179−generates a copy of GHC that has the `mtl` library registered in addition to
180−its normal core packages:
181−
182− $ nix-shell -p "haskellPackages.ghcWithPackages (pkgs: [pkgs.mtl])"
183−
184− [nix-shell:~]$ ghc-pkg list mtl
185− /nix/store/zy79...-ghc-7.10.1/lib/ghc-7.10.1/package.conf.d:
186− mtl-2.2.1
187−
188−This function allows users to define their own development environment by means
189−of an override. After adding the following snippet to `~/.nixpkgs/config.nix`,
190−
191− {
192− packageOverrides = super: let self = super.pkgs; in
193− {
194− myHaskellEnv = self.haskell.packages.ghc7101.ghcWithPackages
195− (haskellPackages: with haskellPackages; [
196− # libraries
197− arrows async cgi criterion
198− # tools
199− cabal-install haskintex
200− ]);
201− };
202− }
203−
204−it's possible to install that compiler with `nix-env -f "<nixpkgs>" -iA
205−myHaskellEnv`. If you'd like to switch that development environment to a
206−different version of GHC, just replace the `ghc7101` bit in the previous
207−definition with the appropriate name. Of course, it's also possible to define
208−any number of these development environments! (You can't install two of them
209−into the same profile at the same time, though, because that would result in
210−file conflicts.)
211−
212−The generated `ghc` program is a wrapper script that re-directs the real
213−GHC executable to use a new `lib` directory --- one that we specifically
214−constructed to contain all those packages the user requested:
215−
216− $ cat $(type -p ghc)
217− #! /nix/store/xlxj...-bash-4.3-p33/bin/bash -e
218− export NIX_GHC=/nix/store/19sm...-ghc-7.10.1/bin/ghc
219− export NIX_GHCPKG=/nix/store/19sm...-ghc-7.10.1/bin/ghc-pkg
220− export NIX_GHC_DOCDIR=/nix/store/19sm...-ghc-7.10.1/share/doc/ghc/html
221− export NIX_GHC_LIBDIR=/nix/store/19sm...-ghc-7.10.1/lib/ghc-7.10.1
222− exec /nix/store/j50p...-ghc-7.10.1/bin/ghc "-B$NIX_GHC_LIBDIR" "$@"
223−
224−The variables `$NIX_GHC`, `$NIX_GHCPKG`, etc. point to the *new* store path
225−`ghcWithPackages` constructed specifically for this environment. The last line
226−of the wrapper script then executes the real `ghc`, but passes the path to the
227−new `lib` directory using GHC's `-B` flag.
228−
229−The purpose of those environment variables is to work around an impurity in the
230−popular [ghc-paths](http://hackage.haskell.org/package/ghc-paths) library. That
231−library promises to give its users access to GHC's installation paths. Only,
232−the library can't possible know that path when it's compiled, because the path
233−GHC considers its own is determined only much later, when the user configures
234−it through `ghcWithPackages`. So we [patched
235−ghc-paths](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/ghc-paths-nix.patch)
236−to return the paths found in those environment variables at run-time rather
237−than trying to guess them at compile-time.
238−
239−To make sure that mechanism works properly all the time, we recommend that you
240−set those variables to meaningful values in your shell environment, too, i.e.
241−by adding the following code to your `~/.bashrc`:
242−
243− if type >/dev/null 2>&1 -p ghc; then
244− eval "$(egrep ^export "$(type -p ghc)")"
245− fi
246−
247−If you are certain that you'll use only one GHC environment which is located in
248−your user profile, then you can use the following code, too, which has the
249−advantage that it doesn't contain any paths from the Nix store, i.e. those
250−settings always remain valid even if a `nix-env -u` operation updates the GHC
251−environment in your profile:
252−
253− if [ -e ~/.nix-profile/bin/ghc ]; then
254− export NIX_GHC="$HOME/.nix-profile/bin/ghc"
255− export NIX_GHCPKG="$HOME/.nix-profile/bin/ghc-pkg"
256− export NIX_GHC_DOCDIR="$HOME/.nix-profile/share/doc/ghc/html"
257− export NIX_GHC_LIBDIR="$HOME/.nix-profile/lib/ghc-$($NIX_GHC --numeric-version)"
258− fi
259−
260−## How to create ad hoc environments for `nix-shell`
261−
262−The easiest way to create an ad hoc development environment is to run
263−`nix-shell` with the appropriate GHC environment given on the command-line:
264−
265− nix-shell -p "haskellPackages.ghcWithPackages (pkgs: with pkgs; [mtl pandoc])"
266−
267−For more sophisticated use-cases, however, it's more convenient to save the
268−desired configuration in a file called `shell.nix` that looks like this:
269−
270− { nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7101" }:
271− let
272− inherit (nixpkgs) pkgs;
273− ghc = pkgs.haskell.packages.${compiler}.ghcWithPackages (ps: with ps; [
274− monad-par mtl
275− ]);
276− in
277− pkgs.stdenv.mkDerivation {
278− name = "my-haskell-env-0";
279− buildInputs = [ ghc ];
280− shellHook = "eval $(egrep ^export ${ghc}/bin/ghc)";
281− }
282−
283−Now run `nix-shell` --- or even `nix-shell --pure` --- to enter a shell
284−environment that has the appropriate compiler in `$PATH`. If you use `--pure`,
285−then add all other packages that your development environment needs into the
286−`buildInputs` attribute. If you'd like to switch to a different compiler
287−version, then pass an appropriate `compiler` argument to the expression, i.e.
288−`nix-shell --argstr compiler ghc784`.
289−
290−If you need such an environment because you'd like to compile a Hackage package
291−outside of Nix --- i.e. because you're hacking on the latest version from Git
292−---, then the package set provides suitable nix-shell environments for you
293−already! Every Haskell package has an `env` attribute that provides a shell
294−environment suitable for compiling that particular package. If you'd like to
295−hack the `lens` library, for example, then you just have to check out the
296−source code and enter the appropriate environment:
297−
298− $ cabal get lens-4.11 && cd lens-4.11
299− Downloading lens-4.11...
300− Unpacking to lens-4.11/
301−
302− $ nix-shell "<nixpkgs>" -A haskellPackages.lens.env
303− [nix-shell:/tmp/lens-4.11]$
304−
305−At point, you can run `cabal configure`, `cabal build`, and all the other
306−development commands. Note that you need `cabal-install` installed in your
307−`$PATH` already to use it here --- the `nix-shell` environment does not provide
308−it.
309−
310−# How to create Nix builds for your own private Haskell packages
311−
312−If your own Haskell packages have build instructions for Cabal, then you can
313−convert those automatically into build instructions for Nix using the
314−`cabal2nix` utility, which you can install into your profile by running
315−`nix-env -i cabal2nix`.
316−
317−## How to build a stand-alone project
318−
319−For example, let's assume that you're working on a private project called
320−`foo`. To generate a Nix build expression for it, change into the project's
321−top-level directory and run the command:
322−
323− $ cabal2nix . >foo.nix
324−
325−Then write the following snippet into a file called `default.nix`:
326−
327− { nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7101" }:
328− nixpkgs.pkgs.haskell.packages.${compiler}.callPackage ./foo.nix { }
329−
330−Finally, store the following code in a file called `shell.nix`:
331−
332− { nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7101" }:
333− (import ./default.nix { inherit nixpkgs compiler; }).env
334−
335−At this point, you can run `nix-build` to have Nix compile your project and
336−install it into a Nix store path. The local directory will contain a symlink
337−called `result` after `nix-build` returns that points into that location. Of
338−course, passing the flag `--argstr compiler ghc763` allows switching the build
339−to any version of GHC currently supported.
340−
341−Furthermore, you can call `nix-shell` to enter an interactive development
342−environment in which you can use `cabal configure` and `cabal build` to develop
343−your code. That environment will automatically contain a proper GHC derivation
344−with all the required libraries registered as well as all the system-level
345−libraries your package might need.
346−
347−If your package does not depend on any system-level libraries, then it's
348−sufficient to run
349−
350− $ nix-shell --command "cabal configure"
351−
352−once to set up your build. `cabal-install` determines the absolute paths to all
353−resources required for the build and writes them into a config file in the
354−`dist/` directory. Once that's done, you can run `cabal build` and any other
355−command for that project even outside of the `nix-shell` environment. This
356−feature is particularly nice for those of us who like to edit their code with
357−an IDE, like Emacs' `haskell-mode`, because it's not necessary to start Emacs
358−inside of nix-shell just to make it find out the necessary settings for
359−building the project; `cabal-install` has already done that for us.
360−
361−If you want to do some quick-and-dirty hacking and don't want to bother setting
362−up a `default.nix` and `shell.nix` file manually, then you can use the
363−`--shell` flag offered by `cabal2nix` to have it generate a stand-alone
364−`nix-shell` environment for you. With that feature, running
365−
366− $ cabal2nix --shell . >shell.nix
367− $ nix-shell --command "cabal configure"
368−
369−is usually enough to set up a build environment for any given Haskell package.
370−You can even use that generated file to run `nix-build`, too:
371−
372− $ nix-build shell.nix
373−
374−## How to build projects that depend on each other
375−
376−If you have multiple private Haskell packages that depend on each other, then
377−you'll have to register those packages in the Nixpkgs set to make them visible
378−for the dependency resolution performed by `callPackage`. First of all, change
379−into each of your projects top-level directories and generate a `default.nix`
380−file with `cabal2nix`:
381−
382− $ cd ~/src/foo && cabal2nix . >default.nix
383− $ cd ~/src/bar && cabal2nix . >default.nix
384−
385−Then edit your `~/.nixpkgs/config.nix` file to register those builds in the
386−default Haskell package set:
387−
388− {
389− packageOverrides = super: let self = super.pkgs; in
390− {
391− haskellPackages = super.haskellPackages.override {
392− overrides = self: super: {
393− foo = self.callPackage ../src/foo {};
394− bar = self.callPackage ../src/bar {};
395− };
396− };
397− };
398− }
399−
400−Once that's accomplished, `nix-env -f "<nixpkgs>" -qA haskellPackages` will
401−show your packages like any other package from Hackage, and you can build them
402−
403− $ nix-build "<nixpkgs>" -A haskellPackages.foo
404−
405−or enter an interactive shell environment suitable for building them:
406−
407− $ nix-shell "<nixpkgs>" -A haskellPackages.bar.env
408−
409−# Miscellaneous Topics
410−
411−## How to build with profiling enabled
412−
413−Every Haskell package set takes a function called `overrides` that you can use
414−to manipulate the package as much as you please. One useful application of this
415−feature is to replace the default `mkDerivation` function with one that enables
416−library profiling for all packages. To accomplish that, add configure the
417−following snippet in your `~/.nixpkgs/config.nix` file:
418−
419− {
420− packageOverrides = super: let self = super.pkgs; in
421− {
422− profiledHaskellPackages = self.haskellPackages.override {
423− overrides = self: super: {
424− mkDerivation = args: super.mkDerivation (args // {
425− enableLibraryProfiling = true;
426− });
427− };
428− };
429− };
430− }
431−
432−## How to override package versions in a compiler-specific package set
433−
434−Nixpkgs provides the latest version of
435−[`ghc-events`](http://hackage.haskell.org/package/ghc-events), which is 0.4.4.0
436−at the time of this writing. This is fine for users of GHC 7.10.x, but GHC
437−7.8.4 cannot compile that binary. Now, one way to solve that problem is to
438−register an older version of `ghc-events` in the 7.8.x-specific package set.
439−The first step is to generate Nix build instructions with `cabal2nix`:
440−
441− $ cabal2nix cabal://ghc-events-0.4.3.0 >~/.nixpkgs/ghc-events-0.4.3.0.nix
442−
443−Then add the override in `~/.nixpkgs/config.nix`:
444−
445− {
446− packageOverrides = super: let self = super.pkgs; in
447− {
448− haskell = super.haskell // {
449− packages = super.haskell.packages // {
450− ghc784 = super.haskell.packages.ghc784.override {
451− overrides = self: super: {
452− ghc-events = self.callPackage ./ghc-events-0.4.3.0.nix {};
453− };
454− };
455− };
456− };
457− };
458− }
459−
460−This code is a little crazy, no doubt, but it's necessary because the intuitive
461−version
462−
463− haskell.packages.ghc784 = super.haskell.packages.ghc784.override {
464− overrides = self: super: {
465− ghc-events = self.callPackage ./ghc-events-0.4.3.0.nix {};
466− };
467− };
468−
469−doesn't do what we want it to: that code replaces the `haskell` package set in
470−Nixpkgs with one that contains only one entry,`packages`, which contains only
471−one entry `ghc784`. This override loses the `haskell.compiler` set, and it
472−loses the `haskell.packages.ghcXYZ` sets for all compilers but GHC 7.8.4. To
473−avoid that problem, we have to perform the convoluted little dance from above,
474−iterating over each step in hierarchy.
475−
476−Once it's accomplished, however, we can install a variant of `ghc-events`
477−that's compiled with GHC 7.8.4:
478−
479− nix-env -f "<nixpkgs>" -iA haskell.packages.ghc784.ghc-events
480−
481−Unfortunately, it turns out that this build fails again while executing the
482−test suite! Apparently, the release archive on Hackage is missing some data
483−files that the test suite requires, so we cannot run it. We accomplish that by
484−re-generating the Nix expression with the `--no-check` flag:
485−
486− $ cabal2nix --no-check cabal://ghc-events-0.4.3.0 >~/.nixpkgs/ghc-events-0.4.3.0.nix
487−
488−Now the builds succeeds.
489−
490−Of course, in the concrete example of `ghc-events` this whole exercise is not
491−an ideal solution, because `ghc-events` can analyze the output emitted by any
492−version of GHC later than 6.12 regardless of the compiler version that was used
493−to build the `ghc-events' executable, so strictly speaking there's no reason to
494−prefer one built with GHC 7.8.x in the first place. However, for users who
495−cannot use GHC 7.10.x at all for some reason, the approach of downgrading to an
496−older version might be useful.
497−
498−## How to recover from GHC's infamous non-deterministic library ID bug
499−
500−GHC and distributed build farms don't get along well:
501−
502− https://ghc.haskell.org/trac/ghc/ticket/4012
503−
504−When you see an error like this one
505−
506− package foo-0.7.1.0 is broken due to missing package
507− text-1.2.0.4-98506efb1b9ada233bb5c2b2db516d91
508−
509−then you have to download and re-install `foo` and all its dependents from
510−scratch:
511−
512− # nix-store -q --referrers /nix/store/*-haskell-text-1.2.0.4 \
513− | xargs -L 1 nix-store --repair-path --option binary-caches http://hydra.nixos.org
514−
515−If you're using additional Hydra servers other than `hydra.nixos.org`, then it
516−might be necessary to purge the local caches that store data from those
517−machines to disable these binary channels for the duration of the previous
518−command, i.e. by running:
519−
520− rm /nix/var/nix/binary-cache-v3.sqlite
521− rm /nix/var/nix/manifests/*
522− rm /nix/var/nix/channel-cache/*
523−
524−## Builds on Darwin fail with `math.h` not found
525−
526−Users of GHC on Darwin have occasionally reported that builds fail, because the
527−compiler complains about a missing include file:
528−
529− fatal error: 'math.h' file not found
530−
531−The issue has been discussed at length in [ticket
532−6390](https://github.com/NixOS/nixpkgs/issues/6390), and so far no good
533−solution has been proposed. As a work-around, users who run into this problem
534−can configure the environment variables
535−
536− export NIX_CFLAGS_COMPILE="-idirafter /usr/include"
537− export NIX_CFLAGS_LINK="-L/usr/lib"
538−
539−in their `~/.bashrc` file to avoid the compiler error.
540−
541−## Using Stack together with Nix
542−
543− -- While building package zlib-0.5.4.2 using:
544− runhaskell -package=Cabal-1.22.4.0 -clear-package-db [... lots of flags ...]
545− Process exited with code: ExitFailure 1
546− Logs have been written to: /home/foo/src/stack-ide/.stack-work/logs/zlib-0.5.4.2.log
547−
548− Configuring zlib-0.5.4.2...
549− Setup.hs: Missing dependency on a foreign library:
550− * Missing (or bad) header file: zlib.h
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
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.
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
557− with the verbosity flag -v3 to see the error messages.
558−
559−When you run the build inside of the nix-shell environment, the system
560−is configured to find libz.so without any special flags -- the compiler
561−and linker "just know" how to find it. Consequently, Cabal won't record
562−any search paths for libz.so in the package description, which means
563−that the package works fine inside of nix-shell, but once you leave the
564−shell 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
566−Haskell package that's built inside of nix-shell but run outside of that
567−environment.
568−
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
571−paths and makes them explicit on the "cabal configure" command line. I
572−don't think anyone is working on that subject yet, though, because the
573−problem doesn't seem so bad in practice.
574−
575−You can remedy that issue in several ways. First of all, run
576−
577− $ nix-build --no-out-link "<nixpkgs>" -A zlib
578− /nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8
579−
580−to find out the store path of the system's zlib library. Now, you can
581−
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
584− automatically. It's no pretty solution, but it will work.
585−
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
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.
590−
591−3) The solution I prefer is to call stack with an appropriate
592− --extra-lib-dirs flag like so:
593−
594− $ stack --extra-lib-dirs=/nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8/lib build
595−
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
598− global "~/.stack/global/stack.yaml" file so that you don't have to
599− specify them manually every time.
600−
601− The same thing applies to `cabal configure`, of course, if you're
602− building with `cabal-install` instead of Stack.
603−
604−
605−# Other resources
606−
607−- The Youtube video [Nix Loves Haskell](https://www.youtube.com/watch?v=BsBhi_r-OeE)
608− provides an introduction into Haskell NG aimed at beginners. The slides are
609− available at http://cryp.to/nixos-meetup-3-slides.pdf and also -- in a form
610− ready for cut & paste -- at
611− https://github.com/NixOS/cabal2nix/blob/master/doc/nixos-meetup-3-slides.md.
612−
613−- Another Youtube video is [Escaping Cabal Hell with Nix](https://www.youtube.com/watch?v=mQd3s57n_2Y),
614− which discusses the subject of Haskell development with Nix but also provides
615− a basic introduction to Nix as well, i.e. it's suitable for viewers with
616− almost no prior Nix experience.
617−
618−- Oliver Charles wrote a very nice [Tutorial how to develop Haskell packages with Nix](http://wiki.ocharles.org.uk/Nix).
619−
620−- The *Journey into the Haskell NG infrastructure* series of postings
621− describe the new Haskell infrastructure in great detail:
622−
623− - [Part 1](http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015591.html)
624− explains the differences between the old and the new code and gives
625− instructions how to migrate to the new setup.
626−
627− - [Part 2](http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015608.html)
628− looks in-depth at how to tweak and configure your setup by means of
629− overrides.
630−
631− - [Part 3](http://lists.science.uu.nl/pipermail/nix-dev/2015-April/016912.html)
632− describes the infrastructure that keeps the Haskell package set in Nixpkgs
633− uptodate.