Stack: Stack + nix error

[jagajaga]

Hello! Trying to build my project (https://github.com/serokell/rscoin) using stack at nixos.
Using master branch of nixpkgs with cherry-picked https://github.com/NixOS/nixpkgs/commit/2cbb7bf9d1ce519a480880f257cc569fbe4e6269 commit.
The problem is with zlib.

% NIX_PATH=nixpkgs=/path/to/nixpkgs/repo stack --nix build
rscoin-0.1.0.0: configure
rscoin-0.1.0.0: build

--  While building package rscoin-0.1.0.0 using:
      /home/jaga/.stack/setup-exe-cache/x86_64-linux-nix/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0 build lib:rscoin exe:rscoin-bank exe:rscoin-keygen exe:rscoin-mintette exe:rscoin-user exe:timed-launch --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/Sexy/Serokell/rscoin/.stack-work/logs/rscoin-0.1.0.0.log

    Configuring rscoin-0.1.0.0...
    Preprocessing library rscoin-0.1.0.0...
    [ 1 of 44] Compiling RSCoin.Core.Logging ( src/RSCoin/Core/Logging.hs, .stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0/build/RSCoin/Core/Logging.o )
    [ 2 of 44] Compiling RSCoin.Core.Crypto ( src/RSCoin/Core/Crypto.hs, .stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0/build/RSCoin/Core/Crypto.o )
    <command line>: cant load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)

% NIX_PATH=nixpkgs=/path/to/nixpkgs/repo nix-shell -p git zlib openssh autoreconfHook --command "stack build --force-dirty"
msgpack-1.0.0: unregistering (local file changes: )
msgpack-aeson-0.1.0.0: unregistering (missing dependencies: msgpack)
msgpack-rpc-1.0.0: unregistering (missing dependencies: msgpack)
rscoin-0.1.0.0: unregistering (missing dependencies: msgpack, msgpack-aeson, msgpack-rpc, serokell-core)
serokell-core-0.1.0.0: unregistering (local file changes: )
msgpack-1.0.0: build
serokell-core-0.1.0.0: configure
msgpack-1.0.0: copy/register
msgpack-rpc-1.0.0: build
msgpack-aeson-0.1.0.0: build
msgpack-aeson-0.1.0.0: copy/register
serokell-core-0.1.0.0: build
msgpack-rpc-1.0.0: copy/register
serokell-core-0.1.0.0: copy/register
rscoin-0.1.0.0: build
rscoin-0.1.0.0: copy/register
Completed 5 action(s).

My stack.yaml contains

...
nix:
    packages: [git,zlib,openssh,autoreconfHook]
...

cc @peti @volhovm btw

[mgsloan]

See this thread https://groups.google.com/forum/#!msg/haskell-stack/_ZBh01VP_fo/0v4SxPw7GwAJ + dupe stack issue https://github.com/commercialhaskell/stack/issues/1028

Apparently this is due to https://ghc.haskell.org/trac/ghc/ticket/11042

Seems like the resolution is to add pkgconfig-depends: zlib, or something like that, to your cabal file. I suppose ideally this would be in the zlib cabal file itself.

Feel free to re-open if this isn't the issue.

[jagajaga]

Thank you! I will check it out.

[PierreR]

I have the same problem ... I doesn't seem to be a duplicate of #1028 because it does not work even while using nix-shell -p zlib and at the time of the issue stack --nix build didn't exist (apparently).

It has been working for me using the nix-stable channel with an older version of stack (1.02). I have just switched to the unstable channel with stack 1.1.0 x86_64 hpack-0.13.0 and I now have the same cant load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory).

I have been trying the suggested fixes from the linked google thread without success so far.

[jagajaga]

@PierreR doesn't % NIX_PATH=nixpkgs=/path/to/nixpkgs/repo nix-shell -p git zlib openssh autoreconfHook --command "stack build --force-dirty" work for you?

[PierreR]

If I try nix-shell -p git zlib openssh autoreconfHook --command "stack build --force-dirty" it does not work.
I am not quite sure why you want to set the NIX_PATH again. Do you want me to have a go with the stable channel ?

Using nix-shell --command "stack --no-nix build" works. Maybe something is broken in the latest stack & --nix flag ?

[PierreR]

I really don't get ... It has been working fine for months with the stable nixos channel.

I have just tried installing the previous stack version in user space but it is still failing.On the other hand using the stable derivation set with NIX_PATH=nixpkgs=/path/to/nixpkgs/repo nix-shell -p git zlib openssh autoreconfHook --command "stack build --force-dirty" produces the same error.

I just don't seem to be able to understand what change exactly introduces the problem ... Trying it in user space, neither the version of stack or the version of nixpkgs seems to make a difference. I guess the only way to get to the previous working state is to switch (rollback) to an older nixos derivation all together (or to abandon the idea of stack --nix).

[PierreR]

Would be nice to re-open the issue (even if it might not be related to stack per se) just in case someone has a quick workaround I could try.

[PierreR]

I have found a workaround !

If I use:

nix:
  enable: true
  shell-file: shell.nix

instead of

nix:
  enable: true
  packages: [glpk, pcre, zlib, ruby]

Then I update the default.nix to include all system dependencies (with libraryPkgconfigDepends = [ ruby glpk pcre zlib ]; , then it works (no more cant load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)

I still don't know why it has suddenly stop to work with the usual setting.

[jagajaga]

@PierreR can you share your shell.nix?

[PierreR]

My shell.nix is not doing much, everything is done in default.nix that has been generated by cabal2nix + the few tweaks I described above:

with (import <nixpkgs> {}).pkgs;
(haskellPackages.callPackage ./. {}).env

Here is the default.nix in case it is of interest:

{ mkDerivation, aeson, ansi-wl-pprint, attoparsec, base
, base16-bytestring, bytestring, case-insensitive, containers
, cryptonite, directory, either, exceptions, filecache, formatting
, Glob, hashable, hruby, hslogger, hslua, hspec, hspec-megaparsec
, HUnit, lens, lens-aeson, megaparsec, memory, mtl, operational
, optparse-applicative, parallel-io, parsec, pcre-utils, process
, random, regex-pcre-builtin, scientific, semigroups, servant
, servant-client, split, stdenv, stm, strict-base-types, temporary
, text, time, transformers, unix, unordered-containers, vector
, yaml, ruby, glpk, pcre, zlib
}:
mkDerivation {
  pname = "language-puppet";
  version = "1.1.5.1";
  src = ./.;
  isLibrary = true;
  isExecutable = true;
  libraryHaskellDepends = [
    aeson ansi-wl-pprint attoparsec base base16-bytestring bytestring
    case-insensitive containers cryptonite directory either exceptions
    filecache formatting hashable hruby hslogger hslua hspec lens
    lens-aeson megaparsec memory mtl operational parsec pcre-utils
    process random regex-pcre-builtin scientific semigroups servant
    servant-client split stm strict-base-types text time transformers
    unix unordered-containers vector yaml
  ];
  executableHaskellDepends = [
    aeson base bytestring containers either Glob hslogger lens
    megaparsec optparse-applicative parallel-io regex-pcre-builtin
    servant-client strict-base-types text unordered-containers vector
    yaml
  ];
  testHaskellDepends = [
    ansi-wl-pprint base either Glob hslogger hspec hspec-megaparsec
    HUnit lens megaparsec mtl scientific strict-base-types temporary
    text unix unordered-containers vector
  ];
  libraryPkgconfigDepends = [ ruby glpk pcre zlib ];
  homepage = "http://lpuppet.banquise.net/";
  description = "Tools to parse and evaluate the Puppet DSL";
  license = stdenv.lib.licenses.bsd3;
}

[jagajaga]

Thank you!

[jagajaga]

But indeed I think this bug is still relevant and unique.

[jagajaga]

So I think we need to reopen it.

[jagajaga]

Seems like the resolution is to add pkgconfig-depends: zlib, or something like that, to your cabal file. I suppose ideally this would be in the zlib cabal file itself.

That didn't help.

[Pitometsu]

@mgsloan thank you! Anyone yet reported to zlib package authors?
Also, I can see in zlib.cabal extra-libraries: z: isn't it enough, so couldn't _stack_ use that information to handle external library dependency with _nix_?

[puffnfresh]

@Pitometsu if Stack did #1683 then it would be appropriately mapped using the work in cabal2nix:

https://github.com/NixOS/cabal2nix/blob/c886f87a5d347db076f462de11ca7676b15bea34/distribution-nixpkgs/src/Distribution/Nixpkgs/Haskell/FromCabal/Name.hs#L180

[Pitometsu]

@puffnfresh that issue closed. Isn't it implemented yet so?

[YPares]

@PierreR I can confirm that the bug is reproducible on Ubuntu.
On commit 1c20f0b of https://github.com/bartavelle/language-puppet I applied this patch:

diff --git a/language-puppet.cabal b/language-puppet.cabal
index 039852c..ebdce26 100644
--- a/language-puppet.cabal
+++ b/language-puppet.cabal
@@ -81,6 +81,7 @@ library
   extensions:          OverloadedStrings, BangPatterns
   ghc-options:         -Wall -funbox-strict-fields -j1
   -- ghc-prof-options:    -auto-all -caf-all
+  pkgconfig-depends: zlib
   build-depends:       aeson                >= 0.8
                      , ansi-wl-pprint       == 0.6.*
                      , attoparsec           >= 0.12
diff --git a/stack.yaml b/stack.yaml
index e883a7c..5a66b16 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -4,3 +4,6 @@ packages:
 extra-deps:
 - hruby-0.3.3
 resolver: lts-5.4
+nix:
+  enable: true
+  packages: [glpk, pcre, zlib, ruby, pkgconfig]

And when I build with either stack build --nix-pure or --no-nix-pure I'm getting

[ 4 of 50] Compiling Puppet.Paths     ( Puppet/Paths.hs, .stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0/build/Puppet/Paths.o )
<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)
Completed 2 action(s).

[YPares]

@PierreR Okay, your fix doesn't work for me on Ubuntu.
I'm also using the shell.nix and added libraryPkgconfigDepends = [ ruby glpk pcre zlib ];
to default.nix, and the same error happens.
EDIT: Sorry, actually I had reverted my changes and had accidentally removed pkgconfig-depends: zlib from the cabal file. But after re-adding it there's a new error:

setup-Simple-Cabal-1.22.5.0-ghc-7.10.3: The pkg-config package 'zlib' is
required but it could not be found.

I also added extra-libraries: z to the cabal file and re-generated default.nix, that didn't change.

[PierreR]

@YPares Is it possible for you to quickly check if downgrading nix changes anything ?
FWIW I think the cabal file doesn't matter much apart from being the source for the generation of default.nix. Just to be sure you do use shell-file: shell.nix in stack.yaml ?

[YPares]

@PierreR "do you use shell-file: shell.nix in stack.yaml ?"
Yes.

[PierreR]

@YPares I have no idea why the workaround does not work on Ubuntu with nix.

I do believe there is a bug somewhere but I have no idea what is it ;-) It is quite a shame because this stack/nix integration is awesome.

Somehow it seems to be related to the nix/nixpkgs version. Maybe something changes and stack hasn't taken it into account yet.

Since the issue is closed it is probably completely ignored by stack maintainers. So the first step would be to reopen the issue (which I cannot do) or create a new one.

[mgsloan]

Nah, we still get notifications for closed issues. I'm just not very familiar with the nix side of things. Re-opening the issue.

[PierreR]

I have just realized something quite odd.

When I use shell-file: shell.nix instead of packages:[glpk, pcre, zlib, ruby], stack is storing packages in .stack/snapshots/x86_64-linux instead of .stack/snapshots/x86_64-linux-nix ...

So now I suspect it actually works with shell-file because it does not use the nix packages (but the stack one).

In both case nix enable is set to true so it does not make much sense to me ... Anyhow it means that my workaround does not work ...

[PierreR]

@jagajaga Is there a possibility that the issue is related to https://github.com/NixOS/nixpkgs/issues/14967 ? Same kind of problem but with libstdc++.so

[jagajaga]

@PierreR I think not, because that problem was solved and this problem is still present.

[PierreR]

@jagajaga Yes I know. I was wondering if the problem for zlib could be similar to this one about libstdc++. I guess it is unlikely though.

[PierreR]

nix-unstable channel seems really unstable currently so I have moved back to the nix-stable-16.03 channel.

Just to confirm that it works fine on the current nixos stable channel. It has nix version 1.11.2 and stack 1.0.2 x86_64

On the other hand, the unexpected behaviour of shell-file key is already present: if I use shell-file: shell.nix instead of packages:[pcre, zlib, ruby], stack is storing packages in .stack/snapshots/x86_64-linux instead of .stack/snapshots/x86_64-linux-nix. If someone can confirm this issue with the latest stack version, I would open a new issue for it.

[YPares]

@PierreR Yes, same behaviour here. That's weird as nix support is flagged as activated in both cases.

Indeed, we lack a nix-testing channel :)

[YPares]

@PierreR Hi! Have you retried the original issue with a more recent state of nix-unstable?
Have you opened an issue re .stack/snapshots/x86_64-linux-nix?

[YPares]

@PierreR Ok so I opened the issue if you have any input to provide:
https://github.com/commercialhaskell/stack/issues/2258

[yorickvP]

Recently, nix split a whole bunch of packet outputs. Stack seems to be using zlib.static by default, which obviously doesn't include the .so file. Specifying packages: [zlib.dev, zlib.out] works for me.

[YPares]

@yorickvP Do you have to specifiy zlib.out? Isn't zlib.dev enough?
BTW thanks, you found the solution to a "zlib.so not found" problem I was having ^^

[yorickvP]

zlib.out contains the zlib.so file, but zlib.dev does not. (https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/zlib/default.nix). I assume both are needed.

[volhovm]

As for me, specifying [zlib.out, zlib.dev] doesn't work on last nixpkgs-unstable. Still getting <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory).

[k0ral]

I can confirm I still have the issue despite all the workarounds suggested up to now, using nixos-unstable channel. Yet I can find libz.so within zlib's main output:

> tree /nix/store/4xpmz206w5issyk2gr2clmwnw45kbn7d-zlib-1.2.8-dev/
/nix/store/4xpmz206w5issyk2gr2clmwnw45kbn7d-zlib-1.2.8-dev/
├── include
│   ├── zconf.h
│   └── zlib.h
├── lib
│   └── pkgconfig
│       └── zlib.pc
└── nix-support
    └── propagated-native-build-inputs

> tree /nix/store/ba44c44578wnkhqq8bj06d7m4qfx49n8-zlib-1.2.8-static
/nix/store/ba44c44578wnkhqq8bj06d7m4qfx49n8-zlib-1.2.8-static
└── lib
    └── libz.a

> tree /nix/store/wwh7mhwh269sfjkm6k5665b5kgp7jrk2-zlib-1.2.8
/nix/store/wwh7mhwh269sfjkm6k5665b5kgp7jrk2-zlib-1.2.8
├── include
│   ├── zconf.h
│   └── zlib.h
├── lib
│   ├── libz.a
│   ├── libz.so -> libz.so.1.2.8
│   ├── libz.so.1 -> libz.so.1.2.8
│   ├── libz.so.1.2.8
│   └── pkgconfig
│       └── zlib.pc
└── share
    └── man
        └── man3
            └── zlib.3.gz

[aljce]

I am also getting this error on nixos-unstable

[ojw]

I have found that I can build a stack project requiring zlib when using resolver: lts-5.7.

I think this might be related to how 5.7 is the latest lts shipped with nixos 16.03?

But all newer resolvers I have tried have had the reported error. I'm trying to figure out why, but have a hard enough time understanding nix that I can't figure out what's different with 5.7.

[Myrl]

@ojw nixos/nixpkgs@641fc0e683a9abf6f128983490a85d9f635b3a32 broke it...

[mdorman]

@Myrl that commit is from 5 days ago, but @ojw was having problems prior to that---and indeed, this thread is a couple of months old---so that doesn't seem pertinent..

[Myrl]

@mdorman I meant that that commit broke the workaround.

[PierreR]

FWIW the only way I can make stack and nix working together - with system deps and after resolver: lts-5.7 - is still by doing

nix:
  enable: true
  shell-file: shell.nix

@Myrl I am pretty sure it is still working after 641fc0e as I am following the unstable-channel closely (updating it yesterday). Note that I am using stackage nightly.

But if I use, --nix alone or with packages: [...] or --no-nix, it will fail to build as soon as there are system deps involved.

I know it doesn't seem to match what @peti is saying but well I have been trying this dozen of times with the unstable-channel for months and it has always behaved this way for me.

I am quite OK adding an extra shell-file with a shell.nix file so I don't bother that much as long as it is working nicely ;-)

I just hope that when http://permalink.gmane.org/gmane.linux.distributions.nixos/20505 is settled, there will be some clear indication, explanation, documentation on how to use both nix and stack together without pain on nixos

[Myrl]

@PierreR I was able to get it working with packages: [ ... ] pre-641fc0e.

[aljce]

@PierreR I find using anything but a shell-file is prone to so many bugs (like the ssl cert bug with git) that I just don't use the stack.yaml support for nix. It makes my debugging life a lot better. I never get this bug when using a shell.nix file.

[PierreR]

@mckeankylej So you don't use stack at all ? My current motivation for using stack (even on nixos) is intero.

[aljce]

@PierreR Oh I use stack for everything. This is my current setup:

~/.stack/config.yaml

nix:
  enable: true
  shell-file: shell.nix

shell.nix

with import <nixpkgs> { };

haskell.lib.buildStackProject {
  name = "sql-server";
  ghc = haskell.packages.ghc7103.ghc;
  buildInputs = [ ncurses # For intero
                        git # To enable git packages in stack.yaml
                        cabal-install  ]; # For stack solver 

}

Every project starts with a shell.nix. Using this setup I avoid basically all the open stack issues with nix. This solves the above issue and works with intero!

[PierreR]

@mckeankylej Thanks for the clarification. Yes, that is basically what I am doing as well ;-)

Except that I have been using a default.nix. I will try your suggestion with just a shell.nix. That might be a nice way to avoid the burden of generating a default.nix with cabal2nix. Thanks for the trick.

[Pitometsu]

But what if project depend on some binaries like postgres? Do you use default.nix in this case, or pure: false?

[aljce]

@Pitometsu
That is the only stack + nix error I haven't been able to solve I didn't know setting pure to false made that work. There is an open bug about that error here: #2282 that you opened.

[PierreR]

@Pitometsu what I am doing currently is to add such a line to default.nix (for instance if you need ruby and cie) :

libraryPkgconfigDepends = [ ruby glpk pcre zlib ];

I wasn't aware of the pure: false option either

[aljce]

@PierreR But then you have to use cabal to build your projects correct? Company policy I have to use stack to build our projects. Also I am loving this hack sharing tread we have going here.

[PierreR]

@mckeankylej No I am using stack, the same way you do. The only difference is that I generate a default.nix with cabal2nix per project (for the ones that needs system deps) then I manually modify the default.nix file to add (for instance) the line libraryPkgconfigDepends = [ ruby glpk pcre zlib ];.

Ideally it should not be necessary to add this line but I guess there is a bug somewhere. I barely understand how the nix/stash integration works. I am just trying to have something that works ;-)

I would be happy to explore any other avenue. I just know that this one has been working reliably so far for me.

[PierreR]

If I understood @peti correctly stack supposedly found all system deps´ automatically whether you use--nix` or not but it has never been working like that for me ... So I am happy to hear I am not the only one on that boat ;-)

[peti]

If I understood @peti correctly stack supposedly found all system deps automatically whether you use --nix or not

Well, no, it certainly does not. When run on NixOS, stack usually finds no system dependencies at all. It needs to be told where to find these libraries, and there are several ways to do it. The easiest way is to use the --nix flag, which guesses a proper environment for the build and uses nix-shell to set that environment up. This should work fine, and if it does not, then this is most likely a bug in stack.

The next approach is that you create such an environment manually (i.e. by starting the appropriate nix-shell command), and then run stack inside of it. If that does not work, then your environment is false, i.e. you've made a mistake -- not stack. The downside of this approach is that the compiled binaries may very well not work outside of the temporary environment because no-one guarantees that vital store paths don't get garbage collected.

Last but not least, it is possible to provide appropriate --extra-include-dirs and --extra-lib-dirs to stack. This works just fine without any nix-shells, but it still doesn't quite solve the garbage collection problem. So the next best thing is to create a Nix profile, i.e. in /nix/var/nix/profiles/per-user/$USER/my-proj, and to install all required system dependencies in there. Then add the those search paths to your config.yaml and everything will be fine.

Some people even go as far as configuring

# ~/.stack/config.yaml

extra-include-dirs:
  - /home/foo/.nix-profile/include

extra-lib-dirs:
  - /home/foo/.nix-profile/lib

in their global stack config file, which means that stack will automatically find anything that's installed into the user's main Nix profile.

[Pitometsu]

@peti pretty helpful, thanks a lot. Is that all documented somewhere?

[twshelton]

I'm having similar issues. stack build works but stack --nix build throws an error. I'm somewhat new to Haskell/Stack but would be happy provide any additional details that might help narrow it down.

[sorpaas]

I'm also on nixos-unstable. My issue is that stack --nix build works fine but I can't run stack --nix ghci. I need alsaLib:

nix:
  enable: true
  packages: [alsaLib]

But stack --nix ghci gives me this error:

Configuring GHCi with the following packages: randomnoise
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: libasound.so (libasound.so: cannot open shared object file: No such file or directory)

[volhovm]

I still have this error with zlib in particular. Can't find any way to workaround it without pulling in cabal2nix and other haskell dependencies. It'd be perfect to have shell.nix containing only non-haskell libraries, because other strategy results in conflicts within nix/stack. Anyway, even this doesn't work (under nix-shell with right compiler version, libraryPkgconfigDepends has zlib included):

>stack --extra-include-dirs /nix/stor/nix/store/2zmlykvqx69q5bh1l3jqyhrj2493vqdx-zlib-1.2.8/inclue --extra-lib-dirs /nix/store/2zmlykvqx69q5bh1l3jqyhrj2493vqdx-zlib-1.2.8/lib/ build
...
<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)

--  While building package rscoin-0.1.0.0 using:
      /home/volhovm/code/serokell/rscoin/.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.5.0 build lib:rscoin exe:rscoin-bank exe:rscoin-deploy exe:rscoin-explorer exe:rscoin-hs2purs exe:rscoin-json-demo exe:rscoin-keygen exe:rscoin-mintette exe:rscoin-notary exe:rscoin-user --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

But everything works well if shell.nix uses haskell.lib.buildStackProject (as it's described here) instead of mkDerivation approach (generated with cabal2nix).

[ojw]

@volhovM your link seems to point to a markdown cheatsheet. Was the intended target this? I ask just in case you know another resource with info on using buildStackProject that isn't that one.

(Also btw I totally used your cheatsheet to do that link formatting.)

[volhovm]

@ojw yes, that was a mistake. I've fixed the link.

[remysucre]

Had the same problem with zlib when building threepenny-gui, was able to get around with @mckeankylej 's suggestion editing ~/.stack/config.yaml and shell.nix. This thread is becoming a wiki for nix/stack integration!

[YPares]

I advise you to have a look at https://github.com/commercialhaskell/stack/issues/2282 , these problems were due to nixpkgs splitting some package outputs. It has been solved both for package-list use-case and custom-shell-file use-case.
Everything should be OK for next stack release.

[domenkozar]

For the reference sake, I was able to zlib.so working with following changes:

1) Adding pkgconfig-depends: zlib to the package depending on zlib
2) Using following stack config on the main project:

 nix:
    enable:  true
    packages: [zlib.dev, zlib.out, pkgconfig, haskell.compiler.ghc7103]

I wonder, where should we document Nix+Stack caveats?

[seagreen]

@domenkozar: perhaps here?

[alexvorobiev]

Can requesting haskell.compiler.ghc7103 in packages: contradict what is assumed by resolver:?

[domenkozar]

@alexvorobiev I didn't try it, but I'd expect stack to complain it's missing the correct compiler. I'm not sure if my snippet is the best way to get this going, I guess the most relevant part is zlib.dev, zlib.out.

[aljce]

By @domenkozar that solution will become obsolete soon. Check this out

[domenkozar]

@mckeankylej well that's a tricky to solve. Each package will need to be explicitly specified if zlib needs headers (zlib.dev) or libraries (zlib.out) or both.

I don't know cabal internals, but cabal should have a way to tell if libraries or headers are required, not just a package.

@peti is there a plan how to automatically handle multiple outputs in haskell2nix?

Worst case we go back to just always including package.all output, which means all outputs that a package has.

[peti]

@domenkozar, I suppose we could let the generic Haskell builder process these dependencies with stdenv.lib.getLib and stdenv.lib.getDev. We need (a) the include files and (b) the library files. I guess these two helpers would achieve that transparently in most cases.

[domenkozar]

@peti yes, that's actually very similar to package.all except that it will drop docs and such, so +1.

[aljce]

@domenkozar +1 to getLib and getDev

[domenkozar]

@peti so just like in https://github.com/NixOS/nixpkgs/commit/9ddcd5d4568ce7201b35973632684c98d06aa362

[3noch]

So for someone who is not terribly familiar with nix, how would I go about taking advantage of this new feature? I'm using Nixpkgs 16.09.