Executables with shared libraries fail to run with err "no such file or directory"

Projects fail to build

This is a very confusing error as while example 1 & 2 fail to run an older project of mine still builds while another older project of mine fails, and the files clearly exist.

i have no idea what is causing this, and this error came from nowhere and is stopping me from working on any programming projects.

Some additional info:

  • i have installed go via home-manager through programs.go.enable = true;

  • cargo is also installed via home-manager

  • i am using nixpkgs-unstable

  • i use zsh as my default shell however i can see this error in bash aswell

  • here is my home manager config: GitHub - Cequallium/home.nix: my home-manager configuration

  • i did have nix-ld enabled in my configuration.nix a while ago, but i have since removed it.

Is it something similar to Build go code within a nix shell ?

Hey, thanks for replying. I think it is possible. but after reading your thread i am still confused as to how you resolved the issue.

also one more thing, i noticed your reproducer imported net/http and my project did too, so i tested by removing it and compiling it. it ran perfectly without any errors.

Since we were not having any logical solution, we decided to delete the Amazon Workspace and recreate a new one.

We re-did the same build on the new machine and it worked immediately.

oh, i cant do that as i am running this code on my personal system. I would really prefer not to do a full wipe right now. ill keep it in mind though.

For at least Example 2, it’s likely linked against a shared library that it can’t find. – I’m guessing mason is downloading precompiled binaries. On most Linux systems, this would work because the shared libraries are in places those precompiled binaries will look. On NixOS, it will likely cause issues.

For gopls, I’d recommend using nix-shell (or equivalent).

For the other cases, first thing I’d check is running ldd against those binaries to see that it can find all the shared libraries the binary is linked against. e.g. ldd ./main.go.

I am having the same issue. I use docker as a workaround as I couldn’t find any solution

1 Like

Hi, I tried this and i checked all the links, they all seem to exist.
As with gopls it used to work perfectly as did all the other executables and they all broke randomly at the same time. So i included it as i felt it was related.

$ ldd --verbose ./main
        linux-vdso.so.1 (0x00007ffdfafba000)
        libresolv.so.2 => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libresolv.so.2 (0x00007f598a59c000)
        libpthread.so.0 => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libpthread.so.0 (0x00007f598a597000)
        libc.so.6 => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6 (0x00007f598a3aa000)
        /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/ld-linux-x86-64.so.2 => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib64/ld-linux-x86-64.so.2 (0x00007f598a5af000)

        Version information:
                libc.so.6 (GLIBC_2.34) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.32) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.3.2) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.2.5) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_ABI_DT_RELR) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.14) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.4) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.34) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_PRIVATE) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.3.4) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.2.5) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.3) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_ABI_DT_RELR) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                libc.so.6 (GLIBC_2.2.5) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libc.so.6
                ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib64/ld-linux-x86-64.so.2
                ld-linux-x86-64.so.2 (GLIBC_2.3) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib64/ld-linux-x86-64.so.2
                ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib64/ld-linux-x86-64.so.2

A few questions / observations:

Example 1

With go run, the files are copied to a temporary location, so that’s not weird. Printing the executable path for catsay-go shows the following:

$ go run Catsay.go
 Usage: catsay <Phrase> <Color (1 to 8)>
 Colors:  1  2  3  4  5  6  7  8 
import (

func main() {
	// print current path
	ex, err := os.Executable()
	if err != nil {
	exPath := filepath.Dir(ex)

Could this be an issue with the project? Does it build normally?

Example 2

Mason won’t work normally with Nix, so you need to either install the tools you need in your system or add them to neovim:

Cannot install gopls using mason.nvim - #2 by eljamm

However, don’t forget to remove the tools that have already been downloaded by going to the Mason menu, hovering over them, then pressing X. running :MasonUninstallAll

If you want to share your config between NixOS and other distros, you can do something like this:

NeoVim cannot start lsp because clangd is not found - #4 by eljamm

So in NixOS, nvim will use the system/home-manager tools while in other distros, Mason will install the binaries as usual.

Example 3

This works on my machine. What happens when you delete target/ and run cargo run again?

Hi thanks for taking the time to contribute

  • The project from Example 1 is GitHub - Cequallium/whispers: a plaintext blog
    it built perfectly in its current state (latest commit)
  • Example 2:
    I’ll certainly do that from now on.
  • Example 3:
    huh, it does start working. Is this a go specific issue?
1 Like

The person in this comment faced a similar issue and suggested deleting the target/ folder for Rust. Does the Go project from example 1 work when you delete whispers and rebuild?

No, it does not work.

Comparing with your previous ldd --verbose ./main, the main difference is the following:

- /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/ld-linux-x86-64.so.2 => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib64/ld-linux-x86-64.so.2 (0x00007f598a5af000)
+ /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/ld-linux-x86-64.so.2 => /nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib64/ld-linux-x86-64.so.2 (0x00007f37efd52000)

You have glibc-2.39-5 pointing to glibc-2.39-31. Would this probably be the cause of the issue?


$ LD_PRELOAD="/nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/ld-linux-x86-64.so.2" ./whispers
Floating point exception (core dumped)
$ LD_PRELOAD="/nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/ld-linux-x86-64.so.2" ./whispers
whispering on http://localhost:8080/

This might be related to this:

In effect, one of the packages in your home.nix/dev.nix might be interfering with go.

If you try this, does it work?

$ nix-shell --pure -p go
$ go run ./main.go

Just to rule out anything weird, which go are you using for Example 1? which go? (& how was it installed).

My understanding of the issue is it’s something to do with shared libraries & dynamic linking.

(e.g. Without net/http, the go programs don’t link against shared libraries for that case).

You’re totally right, it is related to shared libraries

$ which go

$ whereis go
go: /nix/store/vqwb13qqvqnmqksxpv5s7b1kf0vd50cf-home-manager-path/bin/go

No, it unfortunately does not.

Just to add more information, i did have nix-ld enabled in my configuration.nix a while ago, but i have since removed it.

What does running type -a gcc give you?

Looking at the nix-ld readme, it suggests running an executable with the environment variable LD_DEBUG=libs to figure out what libs are missing.

1 Like

it doesnt seem to work

$ LD_DEBUG=libs ./main
zsh: no such file or directory: ./main