Example 1: go fails to build and run .go files
[LIKELY UNRELATED] Example 2: gopls installed with mason fails to run
[RESOLVED ] Example 3: cargo fails to run a project
Example 4: (contradictory) go successfully builds and runs an older project
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.
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.
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.
drupol
May 14, 2024, 10:17am
4
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.
$ 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:
./main:
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
/nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libresolv.so.2:
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
/nix/store/apab5i73dqa09wx0q27b6fbhd1r18ihl-glibc-2.39-31/lib/libpthread.so.0:
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
/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
/tmp/go-build596412124/b001/exe
Usage: catsay <Phrase> <Color (1 to 8)>
Colors: 1 2 3 4 5 6 7 8
Catsay.go
import (
"fmt"
"os"
"path/filepath"
)
func main() {
// print current path
ex, err := os.Executable()
if err != nil {
panic(err)
}
exPath := filepath.Dir(ex)
fmt.Println(exPath)
...
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
Example 2:
Example 3:
1 Like
eljamm
May 14, 2024, 4:15pm
11
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?
eljamm
May 14, 2024, 4:38pm
13
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?
Edit:
$ 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:
I have found the culprit. When I was fiddling with LSPs and neovim, I put clang under home.packages, which also put ld (and many other compiler-related applications not supposed to be there) under PATH. Moving them into programs.neovim.extraPackages prevents such pollution.
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
/home/cql/.nix-profile/bin/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.
eljamm
May 14, 2024, 5:39pm
18
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
