Installing via `nix profile` makes `nix` command unusable #655

New issue

Closed

opened 2025-02-03 13:19:45 +00:00 by augustebaum · 3 comments

augustebaum commented

2025-02-03 13:19:45 +00:00

I tried installing Lix with

$ nix profile install nixpkgs-unstable#lix

After this, running nix gave the following errors:

$ nix
nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by nix)
nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixcmd.so)
nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixutil.so)
nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixstore.so)
nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixexpr.so)
nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixmain.so)
nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/2dwbdqxar02j86fj0kcfvs15bavf4dff-aws-crt-cpp-0.29.4/lib/libaws-crt-cpp.so)https://lix.systems/install/

which made it impossible to use nix, e.g. to remove lix.

In the end I solved this when I found a nix binary in my Nix store that I could use to run nix profile rollback, but I don't know what I would have done without this. It was stressful.

Someone on Matrix later informed me that

installing lix into your profile doesn't gain you much as the daemon would still be running CppNix

So I guess this is the issue I ran into? In any case I think a warning on https://lix.systems/install/ is warranted.

I tried installing Lix with ```bash $ nix profile install nixpkgs-unstable#lix ``` After this, running `nix` gave the following errors: ``` $ nix nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by nix) nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixcmd.so) nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixutil.so) nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixstore.so) nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixexpr.so) nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/zvgjy210k4inc0gwbhy0z83ifvaccs2k-lix-2.91.1/lib/liblixmain.so) nix: /nix/store/90yn7340r8yab8kxpb0p7y0c9j3snjam-gcc-13.2.0-lib/lib/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /nix/store/2dwbdqxar02j86fj0kcfvs15bavf4dff-aws-crt-cpp-0.29.4/lib/libaws-crt-cpp.so)https://lix.systems/install/ ``` which made it impossible to use `nix`, e.g. to remove `lix`. In the end I solved this when I found a nix binary in my Nix store that I could use to run `nix profile rollback`, but I don't know what I would have done without this. It was stressful. Someone on Matrix later informed me that > installing lix into your profile doesn't gain you much as the daemon would still be running CppNix So I guess this is the issue I ran into? In any case I think a warning on https://lix.systems/install/ is warranted.

jade commented

2025-02-03 17:41:24 +00:00

Owner

That's extremely weird. This error you're seeing should never happen, since in the nix system as a whole, shared libraries are referred to by their full paths in general.

I can tell you that in the environment this was broken, doing that nix profile install from nixpkgs-unstable but for cppnix will be broken in exactly the same way. This is extremely unlikely to be a Lix bug, unless the broken environment only affects executables built by clang or so, but I'm nonetheless sorry you had to deal with this breakage.

Most likely what you saw here is that you have LD_LIBRARY_PATH or LD_PRELOAD set (perhaps due to some kind of weird wrapper shenanigans in the shell or terminal you're using? check these environment variables), which forces the dynamic loader to load different versions of libraries than specified in the executables themselves, and specifically it's overriding libc++abi to an older version than Lix was built with, which is causing it to be very unhappy.

If this happens again you can get a usable nix by looking in /nix/var/nix/profiles. The default profile is the one that the daemon is from and also there's usually previous versions of that profile too.

That's extremely weird. This error you're seeing should never happen, since in the nix system as a whole, shared libraries are referred to by their full paths in general. I *can* tell you that in the environment this was broken, doing that nix profile install from nixpkgs-unstable but for cppnix will be broken in exactly the same way. This is extremely unlikely to be a Lix bug, unless the broken environment only affects executables built by clang or so, but I'm nonetheless sorry you had to deal with this breakage. Most likely what you saw here is that you have LD_LIBRARY_PATH or LD_PRELOAD set (perhaps due to some kind of weird wrapper shenanigans in the shell or terminal you're using? check these environment variables), which forces the dynamic loader to load different versions of libraries than specified in the executables themselves, and specifically it's overriding libc++abi to an older version than Lix was built with, which is causing it to be very unhappy. If this happens again you can get a usable nix by looking in /nix/var/nix/profiles. The default profile is the one that the daemon is from and also there's usually previous versions of that profile too.

augustebaum commented

2025-02-05 16:25:35 +00:00

Author

Thanks for the quick response.

You're exactly right, I did all this in an environment where LD_LIBRARY_PATH was set. I was in a Python project and I used nix-ld in order to make some Python packages work properly (e.g. numpy). Outside of the environment, nix does not raise the errors mentioned above.

I'll admit I don't fully understand the technical reason behind the catastrophic failure you've given; hence I still think this warrants some docs or deeper fixing, but I'll let Lix developers be the judge. At the very least I'm glad there is closure on the cause of the issue.

Thanks again!

Thanks for the quick response. You're exactly right, I did all this in an environment where `LD_LIBRARY_PATH` was set. I was in a Python project and I used nix-ld in order to make some Python packages work properly (e.g. numpy). Outside of the environment, `nix` does not raise the errors mentioned above. I'll admit I don't fully understand the technical reason behind the catastrophic failure you've given; hence I still think this warrants some docs or deeper fixing, but I'll let Lix developers be the judge. At the very least I'm glad there is closure on the cause of the issue. Thanks again!

jade commented

2025-02-05 16:53:24 +00:00

Owner

I'll admit I don't fully understand the technical reason behind the catastrophic failure you've given; hence I still think this warrants some docs or deeper fixing, but I'll let Lix developers be the judge

Unfortunately this happens to basically every other executable as well. The problem with LD_LIBRARY_PATH is that it's tried first before looking where the executable says to look. The dynamic loader does not have a "additional fallback paths" environment variable so you're just hosed here.

Since the only way we could really do this differently is to only ship static executables, and because it happens with every other executable too, I don't think we would be right to document it because in most scenarios where you have this issue, a pile of other stuff is busted too.

> I'll admit I don't fully understand the technical reason behind the catastrophic failure you've given; hence I still think this warrants some docs or deeper fixing, but I'll let Lix developers be the judge Unfortunately this happens to basically every other executable as well. The problem with LD_LIBRARY_PATH is that it's tried first before looking where the executable says to look. The dynamic loader does not have a "additional fallback paths" environment variable so you're just hosed here. Since the only way we could really do this differently is to only ship static executables, and because it happens with every other executable too, I don't think we would be right to document it because in most scenarios where you have this issue, a pile of other stuff is busted too.