Nixpkgs: glibc: undefined symbol __clock_nanosleep in librt.so

[GuillaumeDesforges]

Describe the bug

Upon trying to run haskell-language-server on current nixpkgs, hitting a Undefined symbol __clock_nanosleep in librt.so

To Reproduce
Steps to reproduce the behavior:

1. nix-build "<nixpkgs>" -A haskell.packages.ghc883.haskell-language-server
2. Run the binary result/bin/haskell-language-server on any valid haskell file, it gives some error on parsing
3. nm -gD /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/librt.so | grep nano gives a U for the symbol __clock_nanosleep

Current glibc is 2.31 while the dependency here is 2.30. Worst: there is not even a __clock_nanosleep symbol in the glibc 2.31 derivation (nix-build "<nixpkgs> -A glibc then nm result/lib/librt.so | grep nano is empty)

Notify maintainers

Metadata

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.57, NixOS, 20.09pre237781.32b46dd897a (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(theo): `"home-manager"`
 - channels(root): `"nixos-20.09pre237781.32b46dd897a"`
 - channels(arsleust): `"home-manager"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
  - haskell.packages.ghc883.haskell-language-server
# a list of nixos modules affected by the problem
module:

[Ma27]

Run the binary result/bin/haskell-language-server on any valid haskell file, it gives some error on parsing

Unfortunately I cannot reproduce this on e5e749869fea79a77eb393742e66b60eebec83c2, haskell-language-server runs perfectly fine there in a 20.09 VM (using glibc231).

I also had to build the package myself today (probably because of the haskell updates from last night that aren't completely built by Hydra) and haskell.packages.ghc883.haskell-language-server resulted in /nix/store/f20kn5gb9ms6b5vlby6mb64vvq59d11s-haskell-language-server-0.2.2.0.

Perhaps the issue will disappear on a newer nixpkgs revision where you get a haskell-language-server linked against the proper libc? AFAIK undefined symbols should already break when linking the executable so trying to use the package from a newer nixpkgs rev may fix this.

[GuillaumeDesforges]

I will close this since it seems not reproducible. Thanks @Ma27 for testing.

[rski]

agh, I'm a bit disappointed because I was having the same issue with libeatmydata and this was filed merely an hour before I searched for it!
Just in case this comes of use to you, I had found this similar-ish issue from the past: https://github.com/NixOS/nixpkgs/issues/94315. Maybe this will be of help to you. The thing I got from it is that running multiple versions of nixpkgs can introduce impurities, and manifest like this, which I definitely do.

[GuillaumeDesforges]

Thanks @rski for sharing this. I think it is indeed an issue with mixing multiple versions of nixpkgs.

I can list all files linked to this specific version using this command (ugh)

sudo find /nix/store -executable -type f > nix_executables.txt | xargs ldd | perl -p -e 's/^(\s+)/\1- /g' tmp.txt | perl -p -e 's/^(.+):$/- "\1":/g' | perl -p -e 's/^\s+- (.+)$/  - "\1"/g' | yaml2json | jq '.[] | select(.[]|any(test("xg6ilb9g9zhi2zg1dpi4zcp288rhnvns"))) | keys' nix_executables_ldd.json | jq -s 'flatten'

but there are a lot of them.
I've tried running a few as well, and it seems to run fine.

Also, if I try

nix-store --query --tree /nix/store/kwnwns1ws07njprba8pxspal1ypmi7s6-haskell-language-server-0.2.2.0 | grep xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30

nothing appears, so it is not HLS per se that breaks.

Maybe it has to do with the fact that HLS is linked against another glibc version (2.30) while it calls one of the exe/lib that is against 2.31?..

I'm a bit lost, but definitly something about multiple nixpkgs

[rski]

fwiw, I ended up consolidating all my confix (nixos/nixpkgs) to use a single channel and this went away. As a stab in the dark, I think this might be due to the shell (in my case fish) being linked with one version of glibc, and the executable with another. On exec() the linker might consider the already loaded glibc as fine, resulting in haskell-language-server being dynamically linked with a different version of glibc it was built against.

[GuillaumeDesforges]

I think this happens, but not on the HLS level.
I have noticed that if I delete rm -Rf ~/.stack then rerun HLS, it says at one point:

> [1 of 2] Compiling Main             ( /home/arsleust/.stack/setup-exe-src/setup-mPHDZzAJ.hs, /home/arsleust/.stack/setup-exe-src/setup-mPHDZzAJ.o )
> [2 of 2] Compiling StackSetupShim   ( /home/arsleust/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /home/arsleust/.stack/setup-exe-src/setup-shim-mPHDZzAJ.o )
> Linking /home/arsleust/.stack/setup-exe-cache/x86_64-linux/tmp-Cabal-simple_mPHDZzAJ_3.0.1.0_ghc-8.8.3 ...

and I can inspect:

$ ldd /home/arsleust/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_3.0.1.0_ghc-8.8.3
        linux-vdso.so.1 (0x00007ffc9aaf8000)
        libm.so.6 => /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libm.so.6 (0x00007f136274b000)
        librt.so.1 => /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/librt.so.1 (0x00007f1362741000)
        libutil.so.1 => /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libutil.so.1 (0x00007f136273c000)
        libdl.so.2 => /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libdl.so.2 (0x00007f1362735000)
        libpthread.so.0 => /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libpthread.so.0 (0x00007f1362714000)
        libgmp.so.10 => /nix/store/vw909fhky273h9waklv0fm7m7bn0j4qy-gmp-6.2.0/lib/libgmp.so.10 (0x00007f1362672000)
        libffi.so.7 => /nix/store/6ihjyc8ylagb4s7mbg02zbazldwwwjzk-libffi-3.3/lib/libffi.so.7 (0x00007f1362665000)
        libnuma.so.1 => /nix/store/h38pd7vcaqsaanv6z3qw1i1917kzppbb-numactl-2.0.13/lib/libnuma.so.1 (0x00007f1362656000)
        libc.so.6 => /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/libc.so.6 (0x00007f1362497000)
        /nix/store/xg6ilb9g9zhi2zg1dpi4zcp288rhnvns-glibc-2.30/lib/ld-linux-x86-64.so.2 => /nix/store/aqq6367snc1zh3fs1pc4j4zm5h80vkkz-glibc-2.31/lib64/ld-linux-x86-64.so.2 (0x00007f136288d000)

so I think that:

• all my executables use the 2.31 new version
• somehow this cabal executable compiled upon stack start is linked to the older version

[GuillaumeDesforges]

Resolved

So I was using stack, with nix integration enabled, using a shell.nix file. This shell.nix file was using haskell.nix, which was pinned with another version of nixpkgs than my <nixpkgs>.
This made a mismatch of glibc version, which most likely provoked the issue.

[locallycompact]

@GuillaumeDesforges Do you have this anywhere as an example? I am hitting this same issue and can't figure out how to make haskell.nix use the same nixpkgs.

[GuillaumeDesforges]

https://input-output-hk.github.io/haskell.nix/tutorials/getting-started/#scaffolding

There is

{ # Fetch the latest haskell.nix and import its default.nix
  haskellNix ? import (builtins.fetchTarball "https://github.com/input-output-hk/haskell.nix/archive/master.tar.gz") {}

# haskell.nix provides access to the nixpkgs pins which are used by our CI,
# hence you will be more likely to get cache hits when using these.
# But you can also just use your own, e.g. '<nixpkgs>'.
, nixpkgsSrc ? haskellNix.sources.nixpkgs-2003

# haskell.nix provides some arguments to be passed to nixpkgs, including some
# patches and also the haskell.nix functionality itself as an overlay.
, nixpkgsArgs ? haskellNix.nixpkgsArgs

# import nixpkgs with overlays
, pkgs ? import nixpkgsSrc nixpkgsArgs
}: pkgs.haskell-nix.project {
  # 'cleanGit' cleans a source directory based on the files known by git
  src = pkgs.haskell-nix.haskellLib.cleanGit {
    name = "haskell-nix-project";
    src = ./.;
  };
  # For `cabal.project` based projects specify the GHC version to use.
  compiler-nix-name = "ghc884"; # Not used for `stack.yaml` based projects.
}

you can either change

# haskell.nix provides access to the nixpkgs pins which are used by our CI,
# hence you will be more likely to get cache hits when using these.
# But you can also just use your own, e.g. '<nixpkgs>'.
, nixpkgsSrc ? haskellNix.sources.nixpkgs-2003

to fit the nixpkgs that you used elsewhere (I would not recommand doing that)

# =>
, nixpkgsSrc ? <nixpkgs>

or you can use a pinned version of nixpkgs (recommended), either provided by haskell.nix haskellNix.sources.nixpkgs-2003 or haskellNix.sources.nixpkgs, or https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs

Your development environment (which provides your Stack) and your haskell build (with haskell.nix) should have the same pinned nixpkgs.

[locallycompact]

Thanks, but this does not seem to have worked for me. My set up is in shell.nix file that is pulling in the same version as in the nix/default.nix, but it still errors when trying to the shell provided R with the glibc error.

https://gitlab.com/shakebook-site/shakebook-site.gitlab.io/-/tree/6398cef1267508cc702407e754d728332ea4cbab