This error is popping up when I run stack ghci in a nix shell. But it seems to be an issue only within nix shell. If I run it outside nix-shell, it works just fine (stack is installed via nix-env). I played around with different additions on PATH during nix shell and realized deleting this entry from the PATH made it work fine within the nix-shell too:
In order to reporduce use the following nix shell:
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
name = "haskell-playground";
buildInputs = with pkgs; [
ghc
];
}
<nixpkgs> pointing to nixos-22.11. I’m running ubuntu in WSL.
Full error:
Configuring GHCi with the following packages:
GHCi, version 9.2.5: https://www.haskell.org/ghc/ :? for help
<command line>: /nix/store/9xfad3b5z4y00mzmk2wnn4900q0qmxns-glibc-2.35-224/lib/libc.so.6: undefined symbol: _dl_fatal_printf, version GLIBC_PRIVATE
the gcc-wrapper causing the issue has the following:
addr2line ar as c++ c++filt cc cpp dwp elfedit g++ gcc gprof ld ld.bfd ld.gold nm objcopy objdump ranlib readelf size strings strip
so one of them must be incorrectly linked I assume but unsure what exactly is the problem. Any advise on possible solutions to fix this wrapper or find out why it is not behaving as expected?
I’m having a little trouble following exactly what you’ve tried, and what worked and didn’t work.
My understanding is that you tried the following three things:
Installing stack with nix-env, but not using Stack’s Nix integration when actually building your Haskell project (which means that you would run a command like stack --no-nix build, or at least something like that). In this setup, stack would download a GHC that has been compiled for Ubuntu. Nix basically isn’t used at all in this setup.
We use this setup at my work, and this is expected to work.
Install stack with nix-env, and run stack in some sort of nix-shell that pulls in GHC (even though this GHC gets ignored?) and manipulates the PATH, but you still aren’t using stack's Nix integration.
This doesn’t really make any sense (unless you really know what you’re doing), so I wouldn’t recommend doing this.
Install stack with nix-env, and use Stack’s Nix integration to build your project.
This makes sense, and is how a lot of people use Stack and Nix together.
If you’re using stack, sometimes with Nix and sometimes without Nix, you should be aware that it is really easy to trash your ~/.stack directory. If you see weird linker or compilation errors, I’d recommend the first thing you try is deleting your ~/.stack directory and recompiling.
If you really want to use Haskell with Nix, you might have an easier time using the Haskell infrastructure in Nixpkgs.
I was not aware of the explicit nix intergration initially (using the nix flag/config on stack). The original error happened by simply running stack ghci within a nix-shell so it wouldn’t even open the repl. I was just wondering why would it fail with an error on the gcc-wrapper module and if it can happen to other tools alike which may not have a built in nix integration
Additionally the stack ghci simply fails when running inside nix-shell. Its to do with the gcc-wrapper files being added early on the PATH that is causing the failure (as in one of the gcc-wrapper bins being loaded instead is leading to the failure). It would be useful to understand the cause in case it happened elsewhere since not all tools have a built in nix integration
You start a nix-shell (with ghc for some reason??). This also pulls in GCC and puts it on your path.
You’re using stack, explicitly without the Nix integration. In this mode, Stack will download a GHC that has been compiled and linked against Ubuntu’s normal gcc (located at /usr/bin/gcc / /usr/lib/gcc, or something like that).
When stack tries to load GHCI, either stack, ghc, or gcc is failing because the Nix-supplied gcc libraries are getting picked up, instead of the normal Ubuntu gcc libraries.
Although, I guess you’ve already figured pretty much all of this out.
My suggestion would be that if you intend to use Nix, either go all-in and get all dependencies from Nix, or don’t use Nix. When you try to get some tools from Nix and some from your distro, you can end up with these types of problems. It is sometimes possible to fix if you know what you’re doing (as you’ve found out), but it can be confusing and difficult when you’re first starting out.
Thanks, loading the ghc in nix-shell did not make much difference, I even removed it at one point to see if that was the cause (even a nix-shell with no buildInputs will put a nix gcc wrapper in PATH). I normally try to use everything from nix (in this case my original assumption was that using stack from nixpkgs would be fully nix compatible without extra config but I was wrong)
It may actually be useful to pass the nix flag to the stack distributed via nixpkgs by default since it may not be obvious that extra parameters need to be passed in.
In this mode, Stack will download a GHC that has been compiled and linked against Ubuntu’s normal gcc
Thanks, this is the part I wasn’t 100% certain about and it clears up my doubts and makes the issue clear. Effectively any tool that could download extra binaries can face similar issues so I need to be aware of them whilst using nix in the future
This point is kind of tricky, and it catches some people.
When using stack on NixOS, it defaults to using the Nix integration. When using stack on a different distro, it defaults to not using the Nix integration. This is the same whether or not you get stack from Nixpkgs.
There has been suggestion to default stack in Nixpkgs to using --nix, but we haven’t made this change, since it is possible to get stack from Nixpkgs, but then not use the Nix integration.
I’d have to look it up to be sure, but one of the things people complain about with nix-shell is that even if you don’t pull in any buildInputs, it still puts a few things in your environment (like gcc?). This is actually part of the reason for the split between the new nix develop and nix shell commands. The new nix shell commands works more like you’re expecting, which creates a completely clean environment, without even gcc.