Issues with repo's flake.nix

[arduano]

Hey, just FYI, I've been trying to get this running locally (with the goal of potentially contributing), and it seems like rustc has weird behaviour when building a flake.nix is used for the dev environment.

Here's the error that I was running into:

target/debug/rix: /nix/store/3n58xw4373jp0ljirf06d8077j15pc4j-glibc-2.37-8/lib/libm.so.6: version `GLIBC_2.38' not found (required by target/debug/rix)

Having many other rust projects around, I tried narrowing down what the cause might be. All my other rust projects use a shell.nix, and they were running fine.

Using readelf -d ./target/debug/rix showed that it had a RUNPATH pointing to 2.37, which was identical to the RUNPATH of the rustc that the dev flake required. However, my system rustc's RUNPATH was 2.38.

I tried removing my system's rustup, but that didn't fix it. Compiling inside nix develop -i didn't fix it either. I still haven't found a fix for this, assuming the same flake.lock file.

The only fix was to update the lockfile.

Ideally, it would be good to use a shell.nix as it just inherits the environment's channel which generally avoids issues like this. I understand that a shell.nix isn't as pure as a flake.nix, but purity is hard to implement and implementation issues lead to problems like above.

Also, using flakes for development isn't ideal in general due to issues like this: https://github.com/NixOS/nix/issues/3121 A flake copies the entire non-gitignored environment across, which includes basically the entire repo, even if you don't need it to. A shell.nix on the other hand just runs in-place.

For now I'll just have an updated flake.lock uncommitted in my local repo, but yeah just FYI about this.

[urbas]

Glibc version mismatches are a bit of a drag. However, my guess is that this is not necessarily a problem of flakes.

The problem is likely a hole in the development environment.

I tried to reproduce this on my system (which also uses glibc 2.38), but it all worked alright.

# Here's the ldd output of `target/debug/rix`:
% ldd target/debug/rix
        linux-vdso.so.1 (0x00007ffc84596000)
        libgcc_s.so.1 => /nix/store/v286z87irid5vn13y2z6fphfrzmgj0kf-gcc-12.3.0-lib/lib/libgcc_s.so.1 (0x00007f4946853000)
        libm.so.6 => /nix/store/3n58xw4373jp0ljirf06d8077j15pc4j-glibc-2.37-8/lib/libm.so.6 (0x00007f4946773000)
        libc.so.6 => /nix/store/3n58xw4373jp0ljirf06d8077j15pc4j-glibc-2.37-8/lib/libc.so.6 (0x00007f4944c1a000)
        /nix/store/3n58xw4373jp0ljirf06d8077j15pc4j-glibc-2.37-8/lib/ld-linux-x86-64.so.2 => /nix/store/3n58xw4373jp0ljirf06d8077j15pc4j-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 (0x00007f4946876000)

# Here's the ldd of my system's shell:
% ldd $SHELL
        linux-vdso.so.1 (0x00007ffdf4587000)
        libpcre.so.1 => /nix/store/xgzy8655cm1xq92wy74w8hqs3gqga3hy-pcre-8.45/lib/libpcre.so.1 (0x00007f0720f77000)
        libdl.so.2 => /nix/store/xmprbk52mlcdsljz66m8yf7cf0xf36n1-glibc-2.38-44/lib/libdl.so.2 (0x00007f0720f72000)
        libncursesw.so.6 => /nix/store/2q5w8vspj27v1ah0ggljhb2i8dkdwjg5-ncurses-6.4/lib/libncursesw.so.6 (0x00007f0720efe000)
        librt.so.1 => /nix/store/xmprbk52mlcdsljz66m8yf7cf0xf36n1-glibc-2.38-44/lib/librt.so.1 (0x00007f0720ef9000)
        libm.so.6 => /nix/store/xmprbk52mlcdsljz66m8yf7cf0xf36n1-glibc-2.38-44/lib/libm.so.6 (0x00007f0720e19000)
        libc.so.6 => /nix/store/xmprbk52mlcdsljz66m8yf7cf0xf36n1-glibc-2.38-44/lib/libc.so.6 (0x00007f0720c2e000)
        /nix/store/xmprbk52mlcdsljz66m8yf7cf0xf36n1-glibc-2.38-44/lib/ld-linux-x86-64.so.2 => /nix/store/xmprbk52mlcdsljz66m8yf7cf0xf36n1-glibc-2.38-44/lib64/ld-linux-x86-64.so.2 (0x00007f0720ff3000)

Note that the glibc versions are different, but I was able to run the target/debug/rix executable (even outside the dev env).

This is obviously not the way to reproduce your problem. So, let's try to repro it. In order to do so, I would have to know the exact steps you took to build rix:

• How did you activate the development environment? Did you use nix develop, did you use direnv, or something else?
• How did you invoke rustc? Did you have a preinstalled rustc? Did you call rustc while in the activated development environment?
• Did you do anything even slightly differently than what's described in CONTRIBUTE.md?

[arduano]

How did you activate the development environment?

I did both direnv, and nix develop. Both lead to the same result.

How did you invoke rustc?

I had a preinstalled rustup, but I rebuilt my system without a preinstalled rustup to make sure. Both led to the same result.

Did you do anything even slightly differently than what's described

Nope

---

One possibility is that this could be due to some other compilation toolchain stuff I have installed, such as the linker, etc. The main weird part is that it compiles in the path of glibc 2.37, but expects to find 2.38 in that path. I'm not really sure what could be the cause.

[urbas]

Oh my, yeah, there must be some sort of a hole in the direnv development environment setup.

We rely on rustup and cargo to pull all the Rust tooling down. However, rustup pulls all the stuff into a shared toolchain cache (directly in the user's home folder). This looks like it could be the source of our problems.

I'll try to reproduce this problem by deleting all my rust toolchains, initializing a Rust toolchain outside of rix's development environment, and then build rix inside its dev env.

[arduano]

I attempted manually reinstalling the toolchains iirc, and it still broke. The main thing I wonder about is where does it decide to pull the glibc RPATH/READPATH locations, because that seemed to be the main source of the problem.