hello: "`GLIBC_2.38' not found" when using LD_PRELOAD with the host system's libstdc++ (higher than nixpkgs') #287764

Brogolem35 · 2023-10-22T11:57:22Z

Describe the bug

I installed Nix native package, added the user to the group, and enabled the daemon, as it was stated in the Arch Wiki. For testing I installed the nixpkgs.hello. It was installed successfully but didn't work. The error: hello: /nix/store/whypqfa83z4bsn43n4byvmw80n4mg3r8-glibc-2.37-45/lib/libc.so.6: version GLIBC_2.38' not found (required by /usr/lib/libstdc++.so.6)".
I also tried to install pgadmin4, as it was the reason I installed the Nix. It was also installed successfully but didn't run. The error: "/nix/store/0rwyq0j954a7143p0wzd4rhycny8i967-bash-5.2-p15/bin/bash: /nix/store/whypqfa83z4bsn43n4byvmw80n4mg3r8-glibc-2.37-45/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libstdc++.so.6)"
I also reported this issue on Arch Linux Forum as well, and it seems the problem is related to Nix, as Nix (in stable channel) uses glibc version 2.37-45, but the Arch uses 2.38-7.
Nix being dependent on the libstdc++ might be the root of the issue.

Steps To Reproduce

Install nix package from pacman.
Enable the nix-daemon.service and add the user to the nix-users.
Reboot.
Add the channel nixpkgs-unstable or nixos-23.05 (the problem is present in both versions) and update with nix-.channel --update
Install an application.
Run the installed app.

Expected behavior

Running the installed app without any errors.

nix-env --version output

nix-env (Nix) 2.18.1

Additional context

I use Nix on Arch, btw.

Priorities

Add 👍 to issues you find important.

The text was updated successfully, but these errors were encountered:

abathur · 2023-10-22T14:23:40Z

Sounds similar to:

`GLIBC_2.33' not found nix#6665

Brogolem35 · 2023-10-23T08:22:47Z

Unsetting the LF_PRELOAD seems to do the trick, but it feels not like a solution but a work-around.

iFreilicht · 2023-10-24T08:09:11Z

Nix being dependent on the libstdc++ might be the root of the issue.

True, it should depend on a libstdc++ inside /nix/store. This is definitely a build issue, but the question is whether it originates from the makefiles in the nix repo or the build instructions in the Arch package repository.

Could you try uninstalling nix with pacman and installing it again with the determinate installer? It allows you to uninstall very easily again, so if you do want to run the version packaged by Arch, you can still do that later.

Brogolem35 · 2023-10-24T11:14:01Z

Could you try uninstalling nix with pacman and installing it again with the determinate installer? It allows you to uninstall very easily again, so if you do want to run the version packaged by Arch, you can still do that later.

I tried both the official Nix installer and the one from Determinate Systems before trying to install the programs I mentioned, and both of them crashed during the installation. I am don't know the reason why they crashed but I didn't bother, as the one that Arch shipped was installed successfully. And I now I don't want to uninstall Nix, as it may delete or corrupt my pgadmin4 configurations. But I may try them again in a VM and comeback with the results.

nixos-discourse · 2023-11-06T12:56:49Z

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixpkgs-nixos-unstable-many-package-fail-with-glibc-2-38-not-found/35078/2

SomeoneSerge · 2023-11-06T18:10:10Z

Maybe we start un-setting the LD_* variables in the installer scripts 🤔 (as an opt-out behaviour)

abathur · 2023-11-06T18:50:50Z

Wouldn't that just shift the failures to post-install? (after the installer has told the user they have a working install)

SomeoneSerge · 2023-11-06T18:53:13Z

Right, the nixpkgs software would still be broken. Then we need DT_RPATH back, again?

nixos-discourse · 2023-11-27T19:23:22Z

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/new-install-nix-wants-glibc-2-38-debian-12-has-2-36/36109/3

nixos-discourse · 2023-12-20T02:42:36Z

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/on-nixpkgs-and-the-ai-follow-up-to-2023-nix-developer-dialogues/37087/2

cab404 · 2024-01-14T15:41:03Z

this issue is not only important on Arch — it also affects old environments on NixOS (e.g if you develop on older haskell versions in direnv, and have your system on unstable)

t1endat · 2024-01-19T09:41:51Z

Is it fixed in version 23.11 stable yet, I tried to install it today and check by using command strings /lib/libc.so.6 | grep GLIBC_2.38 and ldd --version and GLIBC_2.38 available, not sure others situation ?

SomeoneSerge · 2024-01-19T11:03:18Z

Hey, I appreciate everyone chiming in, but we should try to keep this relevant and "noise-free". Maybe we should close or lock this issue, and actually open one in Nixpkgs instead.

First off, yes, there has been some work and exploration happening related to this issue, e.g. #248547 and the PRs referenced therein.

The way (glibc's) dynamic loader handles DT_RUNPATH today (compared to DT_RPATH) presents a relatively deep issue to how Nixpkgs chooses to link shared libraries. This is only an issue when using Nixpkgs programs on other (FHS) distributions, and only when they abuse something like LD_LIBRARY_PATH.

This repo is concerned specifically with the development of Nix. Nixpkgs-specific issues (e.g. dynamic loading errors in hello, as opposed to the nix binary) should be reported in https://github.com/NixOS/nixpkgs/issues/.

Before posting any new reports in this issue, please test which libc and libstdc++ the Nix binary ends up loading: try running LD_DEBUG=libs nix --version (similarly, if reporting to Nixpkgs, LD_DEBUG=libs hello) and gist the logs. Do verify the logs mention loading libc.so* from a FHS location like /usr/lib. The logs will also mention why the loader chose to look up the library in /usr/lib. If the logs say that /usr/lib was in the LD_LIBRARY_PATH, you've encountered the exact same issue and reporting it will add noise:

   3479124:     find library=libc.so.6 [0]; searching                                                     
   3479124:      search path=/usr/lib             (LD_LIBRARY_PATH)                   
   3479124:       trying file=/usr/lib/libc.so.6                                   
   3479124:      search path=/nix/store/5k91mg4qjylxbfvrv748smfh51ppjq0g-xxxxxxx-3.11.6/lib             (RUNPATH from file /nix/store/5k91mg4qjylxbfvrv748smfh51ppjq0g-xxxxxxx-3.11.6/bin/xxxxxx)
   3479124:       trying file=/nix/store/5k91mg4qjylxbfvrv748smfh51ppjq0g-xxxxxxx-3.11.6/lib/libc.so.6 
...

FWIW, I tried running LD_DEBUG=libs LD_LIBRARY_PATH=/usr/lib nix --version on my NixOS system with nix deployed from Nixpkgs, and it the logs showed an empty LD_LIBRARY_PATH, indicating that nix probably unsets the variable. So I do not expect this specific issue to be encountered in Nix itself, only in other Nixpkgs-built software like hello:

   3771467:     find library=libc.so.6 [0]; searching                                                                                                                                                                
   3771467:      search path=           (LD_LIBRARY_PATH)

Do report if you get similar errors when using the nix binary and

you've confirmed that your FHS environment doesn't force, in any obvious way, the dynamic loader to use the wrong libc instead of the one Nix directly links to through the RUNPATH;
or you get linkage-related errors with the nixStatic (because it shouldn't involve any dynamic linkage).

@cab404 this shouldn't be an issue if you're not mixing different channels in your dev environment and not mixing the "system" and the dev environment's packages. The issue should only present itself when you try to load a library linked against a newer libc in a process that has already loaded the old libc. This might hypothetically happen with e.g. the impure userspace drivers deployed in /run/opengl-driver/lib in which case you do have to use work-arounds like nixGL. If you're observing this error under different circumstances, please file an issue in Nixpkgs (I'd appreciate a ping too).

If one needs help diagnosing, they should please reach out in the Nix/NixOS support room on matrix, or at https://discourse.nixos.org.

Thanks!

Ashvith10 · 2024-02-09T08:03:24Z

Has this issue been resolved? Because I still have problem launching applications in Nix Flakes on a Guix System.

SomeoneSerge · 2024-02-09T14:00:01Z

Has this issue been resolved? Because I still have problem launching applications in Nix Flakes on a Guix System.

The issue of DT_RUNPATH having a lower priority than LD_LIBRARY_PATH has not been resolved yet.
The issue of distributions potentially abusing the high-priority LD_PRELOAD and LD_LIBRARY_PATH... isn't suggestive of a solution?
The general issue of magically always choosing the newest libc/libstdc++ hasn't been resolved

In which way exactly do applications from nix flakes fail to launch for you on that Guix system?

SomeoneSerge · 2024-02-09T14:02:47Z

Unsetting the LF_PRELOAD seems to do the trick, but it feels not like a solution but a work-around.

@Brogolem35 could you elaborate, what were the contents of LD_PRELOAD and why/how was it set?

Could you confirm that you had an LD_PRELOAD set which forced the newer (Archlinux's) libstdc++ to be loaded, but not the newer libc?

Ashvith10 · 2024-02-09T14:20:12Z

@SomeoneSerge it fails in multiple ways. Before I go explaining the issues, I'll describe what this flake does it has a bunch of build inputs, like Setzer, TexLive and PNPM. Ideally, I want to be able to use nix develop - PNPM to download font icons, TexLive to build PDF via Xelatex and Setzer to get a convinient UI to edit documents.

Here's the log:

$ setzer 

(process:19847): Gtk-WARNING **: 19:41:50.257: Locale not supported by C library.
	Using the fallback 'C' locale.
Fontconfig error: Cannot load default config file: No such file: (null)

** (.setzer-wrapped:19847): WARNING **: 19:41:51.014: Failed to load shared library '/nix/store/rkdck16zm3zpbpy2c8a1vm4bc935v6s8-webkitgtk-2.42.5+abi=6.0/lib/libwebkitgtk-6.0.so.4' referenced by the typelib: /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /nix/store/rkdck16zm3zpbpy2c8a1vm4bc935v6s8-webkitgtk-2.42.5+abi=6.0/lib/libwebkitgtk-6.0.so.4)

** (.setzer-wrapped:19847): WARNING **: 19:41:51.016: Failed to load shared library '/nix/store/rkdck16zm3zpbpy2c8a1vm4bc935v6s8-webkitgtk-2.42.5+abi=6.0/lib/libjavascriptcoregtk-6.0.so.1' referenced by the typelib: /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /nix/store/rkdck16zm3zpbpy2c8a1vm4bc935v6s8-webkitgtk-2.42.5+abi=6.0/lib/libjavascriptcoregtk-6.0.so.1)
/nix/store/dzf369ynm2k3mcpm2p1b8cijp5yr15s8-setzer-62/lib/python3.11/site-packages/setzer/workspace/help_panel/help_panel_viewgtk.py:92: Warning: cannot retrieve class for invalid (unclassed) type 'void'
  self.content = WebKit.WebView()
Traceback (most recent call last):
  File "/nix/store/dzf369ynm2k3mcpm2p1b8cijp5yr15s8-setzer-62/bin/..setzer-wrapped-wrapped", line 87, in do_activate
    self.activate()
  File "/nix/store/dzf369ynm2k3mcpm2p1b8cijp5yr15s8-setzer-62/lib/python3.11/site-packages/setzer/helpers/timer.py", line 25, in new_function
    return_value = original_function(*args, **kwargs)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/dzf369ynm2k3mcpm2p1b8cijp5yr15s8-setzer-62/bin/..setzer-wrapped-wrapped", line 123, in activate
    self.main_window.create_widgets()
  File "/nix/store/dzf369ynm2k3mcpm2p1b8cijp5yr15s8-setzer-62/lib/python3.11/site-packages/setzer/workspace/workspace_viewgtk.py", line 66, in create_widgets
    self.help_panel = help_panel_view.HelpPanelView()
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/dzf369ynm2k3mcpm2p1b8cijp5yr15s8-setzer-62/lib/python3.11/site-packages/setzer/workspace/help_panel/help_panel_viewgtk.py", line 92, in __init__
    self.content = WebKit.WebView()
                   ^^^^^^^^^^^^^^^^
TypeError: could not get a reference to type class

The program does not terminate - it just stops there.

There's a font configuration issue, which I'm not able to figure out how to resolve - because of which, none of the fonts are detected, not even the ones in the flake buildInput, but also local fonts, as well as Guix fonts.
There's a GLIBCXX error, which can be resolved by setting export LD_PRELOAD="${stdenv.cc.cc.lib}/lib/libstdc++.so.6 in the shellHook, but all the other Guix console commands stop working. Alternatively, this is how I run Sezter now, by adding this in the shellHook alias setzer='LD_PRELOAD="${stdenv.cc.cc.lib}/lib/libstdc++.so.6" setzer'
The issue still does not stop there - even after setting this alias, it does not solve my issue:

$ setzer

(process:24081): Gtk-WARNING **: 19:47:49.743: Locale not supported by C library.
	Using the fallback 'C' locale.
Fontconfig error: Cannot load default config file: No such file: (null)
Cannot get default EGL display: EGL_BAD_PARAMETER

** (.setzer-wrapped:24081): WARNING **: 19:47:50.811: Disabled hardware acceleration because GTK failed to initialize GL: Failed to create EGL display.
/nix/store/dzf369ynm2k3mcpm2p1b8cijp5yr15s8-setzer-62/bin/..setzer-wrapped-wrapped:134: DeprecationWarning: Gtk.Widget.show is deprecated
  self.main_window.show()
Gsk-Message: 19:47:51.111: Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkWaylandToplevel': Failed to create EGL display


(process:2): Gtk-WARNING **: 19:47:51.351: Locale not supported by C library.
	Using the fallback 'C' locale.
Fontconfig error: Cannot load default config file: No such file: (null)

(process:2): Gdk-WARNING **: 19:47:51.371: Failed to read portal settings: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files
activate: 1.214327096939087 seconds
MESA-LOADER: failed to open iris: /run/opengl-driver/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /run/opengl-driver/lib/dri, suffix _dri)
MESA-LOADER: failed to open zink: /run/opengl-driver/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /run/opengl-driver/lib/dri, suffix _dri)
MESA-LOADER: failed to open kms_swrast: /run/opengl-driver/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /run/opengl-driver/lib/dri, suffix _dri)
MESA-LOADER: failed to open swrast: /run/opengl-driver/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /run/opengl-driver/lib/dri, suffix _dri)
Failed to create GBM device for render device: /dev/dri/renderD128: No such file or directory
PlatformDisplayLibWPE: could not create the EGL display: EGL_SUCCESS.

Does the app launch now? Yes. Can it build any documents? No.

SomeoneSerge · 2024-02-09T14:38:22Z

library '/nix/store/rkdck16zm3zpbpy2c8a1vm4bc935v6s8-webkitgtk-2.42.5+abi=6.0/lib/libwebkitgtk-6.0.so.4' referenced by the typelib: /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /nix/store/rkdck16zm3zpbpy2c8a1vm4bc935v6s8-webkitgtk-2.42.5+abi=6.0/lib/libwebkitgtk-6.0.so.4)

You're using nixpkgs' webkitgtk but you've already loaded guix's libstdc++ into the failing process, which in this case is apparently older than nixpkgs'. Why, does Guix set any LD_* variables?

Ashvith10 · 2024-02-09T14:46:36Z

You're using nixpkgs' webkitgtk but you've already loaded guix's libstdc++ into the failing process, which in this case is apparently older than nixpkgs'. Why, does Guix set any LD_* variables?

@SomeoneSerge it doesn't look like that.

Normal terminal environment:

$ env | grep -E 'LD'
OLDPWD=/home/ashvith

Nix flake devShell environment:

$ env | grep -E "LD"
NIX_BUILD_CORES=4
shellHook=# alias setzer='LD_PRELOAD="/nix/store/giyri337jb6sa1qyff6qp771qfq10yhf-gcc-12.3.0-lib/lib/libstdc++.so.6" setzer'
LD=ld
NIX_BUILD_TOP=/tmp/nix-shell.91RlkY
DETERMINISTIC_BUILD=1
OLDPWD=
NIX_LDFLAGS=-rpath /home/ashvith/Desktop/resume/outputs/out/lib  -L/nix/store/rac8pxbi1vapwrlqzbrkycbyg521djzw-python3-3.11.6/lib -L/nix/store/j0pi1a69r7zzwxl92c21w1l2syyfnchp-zlib-1.3/lib -L/nix/store/3c7ddcpwhr9ak086n40c9gixvrl6vc0y-bzip2-1.0.8/lib -L/nix/store/xkfhipbvirh4nx07qdl761g3j9fc4nrg-brotli-1.1.0-lib/lib -L/nix/store/dygwk5apknxmxdhwi0j8qz8b1sv6fi2b-libpng-apng-1.6.40/lib -L/nix/store/8v7vqzpnixawf7nsif333gk6dp4y4cyc-freetype-2.13.2/lib -L/nix/store/i5g0zjnqs48lvm5zkv40wbq08gb4qp3x-fontconfig-2.14.2-lib/lib -L/nix/store/ilqbj5n4svk8gc0rg1j9m8dqlbq0ms2p-pixman-0.42.2/lib -L/nix/store/lh04hfa48259q659vw58ayn7pm5nabx7-libXau-1.0.11/lib -L/nix/store/q9bb95bnivn9f596kwrd95vilrcyrr3g-libXext-1.3.5/lib -L/nix/store/fk1vd41g33xbr7s41gjsj1lw5vkqm6c9-libxcb-1.16/lib -L/nix/store/1z9fhkxbyc1nhir2wsini4ngyd9krqdy-libX11-1.8.7/lib -L/nix/store/65gwxgxkk9k86fhdhslazlm1qd8f2hi3-libXrender-0.9.11/lib -L/nix/store/w9x0w0van5d2qdxb5923dxd9d0bid5fp-libffi-3.4.4/lib -L/nix/store/k18y3f2xnzw0jzqwrhz8s3xwkk8w1p0i-gettext-0.21.1/lib -L/nix/store/a9i5isnbiz1nbxskjxmjgs9kdx2ijm5z-glib-2.78.3/lib -L/nix/store/b3f2inmyyc6dz7270mzn4iqxypgza10h-cairo-1.18.0/lib -L/nix/store/rac8pxbi1vapwrlqzbrkycbyg521djzw-python3-3.11.6/lib -L/nix/store/j0pi1a69r7zzwxl92c21w1l2syyfnchp-zlib-1.3/lib -L/nix/store/3c7ddcpwhr9ak086n40c9gixvrl6vc0y-bzip2-1.0.8/lib -L/nix/store/xkfhipbvirh4nx07qdl761g3j9fc4nrg-brotli-1.1.0-lib/lib -L/nix/store/dygwk5apknxmxdhwi0j8qz8b1sv6fi2b-libpng-apng-1.6.40/lib -L/nix/store/8v7vqzpnixawf7nsif333gk6dp4y4cyc-freetype-2.13.2/lib -L/nix/store/i5g0zjnqs48lvm5zkv40wbq08gb4qp3x-fontconfig-2.14.2-lib/lib -L/nix/store/ilqbj5n4svk8gc0rg1j9m8dqlbq0ms2p-pixman-0.42.2/lib -L/nix/store/lh04hfa48259q659vw58ayn7pm5nabx7-libXau-1.0.11/lib -L/nix/store/q9bb95bnivn9f596kwrd95vilrcyrr3g-libXext-1.3.5/lib -L/nix/store/fk1vd41g33xbr7s41gjsj1lw5vkqm6c9-libxcb-1.16/lib -L/nix/store/1z9fhkxbyc1nhir2wsini4ngyd9krqdy-libX11-1.8.7/lib -L/nix/store/65gwxgxkk9k86fhdhslazlm1qd8f2hi3-libXrender-0.9.11/lib -L/nix/store/w9x0w0van5d2qdxb5923dxd9d0bid5fp-libffi-3.4.4/lib -L/nix/store/k18y3f2xnzw0jzqwrhz8s3xwkk8w1p0i-gettext-0.21.1/lib -L/nix/store/a9i5isnbiz1nbxskjxmjgs9kdx2ijm5z-glib-2.78.3/lib -L/nix/store/b3f2inmyyc6dz7270mzn4iqxypgza10h-cairo-1.18.0/lib

SomeoneSerge · 2024-02-09T15:11:00Z

@Ashvith10 you'll need then to scan LD_DEBUG=libs setzer |& less (I guess) and find out where /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6 came from.

For future posters: please do go through these steps (adjusted to your environment) in advance and attach information on what configuration exactly leads to the failure:

Which libc/libstdc++ versions your nixpkgs is using.
Which libc/libstdc++ versions your host distribution uses.
The path of the libc actually loaded, the path to the libstdc+++ actually loaded.
Why did the linker choose to load one (e.g. nixpkgs) over the other (e.g. host distribution): which ld.so (ld-linux.so) was used, was it ask to LD_PRELOAD something, did one of the parties override the normal behaviour of the linker using LD_LIBRARY_PATH, was the path picked up from DT_RUNPATH or Guix-style per-dso ld.so.cache, or from the host's global /etc/ld.so.conf

Again, if you need help inferring those, please do reach out e.g. in the Nix/NixOS Support room on Matrix

Ashvith10 · 2024-02-09T17:16:57Z

@SomeoneSerge I figured out a fix - well, it's not really a fix, but a workaround for anyone who's okay with using a dated version of Nix channel. I had to check which version of libc and libc++ I had on my device, so I did:

$ strings /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.14
GLIBC_2.6
GLIBC_2.33
GLIBC_2.4
GLIBC_2.18
GLIBC_2.16
GLIBC_2.32
GLIBC_2.17
GLIBC_2.3.2
GLIBC_2.34
GLIBCXX_DEBUG_MESSAGE_LENGTH

Not a proper deduction, but from this, I realized that apps in 23.05 and 23.11 will definitely not run, as the default gcc version on Guix is 11.3.0, but on NixOS 23.05 and 23.11, they're on 12.2.0 and 12.3.0 respectively. Which means that most of the apps would require GLIBCXX_3.4.30. Right now, I downgraded my flake input url to 22.11. It works fine for me now, and hopefully, this could be helpful for someone else.

SomeoneSerge · 2024-02-09T18:19:36Z

@Ashvith10 none of this should ever be required. You would help the community if you had managed to figure out why does the loader "incorrectly" choose the libstdc++ deployed by Guix. It shouldn't.

Ashvith10 · 2024-02-10T04:17:55Z

@SomeoneSerge I wish I knew how to read trace from LD_DEBUG=libs setzer. Here's the details from my console: dump.log

Ashvith10 · 2024-02-10T04:18:36Z

I think the issues probably starts from here?

SomeoneSerge · 2024-02-10T07:31:56Z

10864:	calling init: /run/current-system/profile/lib/gio/modules/libgioenvironmentproxy.so
...
10864:	find library=libstdc++.so.6 [0]; searching
10864:	 search path=...:/gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../..		(RUNPATH from file /run/current-system/profile/lib/gio/modules/libgiolibproxy.so)
    10864:	calling init: /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6

I don't see what's loading libgioenvironment and why it's a path in /run, but at least we see that /run/current-system is how we reach /gnu

EDIT:

My guess is that we don't see any look-up process for libgioenvironmentproxy because it must've been loaded by absolute path rather than by name. This very likely happens because of some of the global configuration deployed by Guix. I'm not familiar with GIO but I imagine it's something mildly cursed, maybe akin to nsswitch.

You're observing an error because none of the nix-built programs loaded before libgio... depend on libstdc++ so they do not load it. The GIO "plugins" deployed by Guix do, and their libstdc++ is loaded first. The nix-built libwebkitgtk-6.0.so.4 loaded later needs a newer libstdc++ but its space is already occupied

EDIT:

I wish I knew how to read trace from LD_DEBUG=libs setzer

That's quite ok, that's why I suggested reaching out in the chat

Brogolem35 · 2024-02-10T09:36:59Z

Unsetting the LF_PRELOAD seems to do the trick, but it feels not like a solution but a work-around.

@Brogolem35 could you elaborate, what were the contents of LD_PRELOAD and why/how was it set?

Could you confirm that you had an LD_PRELOAD set which forced the newer (Archlinux's) libstdc++ to be loaded, but not the newer libc?

I used set it in .zshrc with export LD_PRELOAD=/usr/lib/libstdc++.so.6.

The reason why I set it was that for some reason the matplotlib that was shipped by conda required it to work.

Ashvith10 · 2024-02-10T09:44:13Z

@Brogolem35 so in your case, it isn't even able to detect system's shared object, let alone Nix, I presume? But then, since you're on Arch, your system's and Nix's shared object must have a small version gap? What you're doing is still not a fix - it's merely a workaround, just like my suggestion above, and most of the apps on older channels won't work, which can be quite a hindrance for anyone using it for production.

SomeoneSerge · 2024-02-10T10:56:44Z

 I used set it in .zshrc with export LD_PRELOAD=/usr/lib/libstdc++.so.6.

Ok, so it wasn't a Nixpkgs issue, and it wasn't an Archlinux issue either. Thanks for expounding this! The resolution is that LD_PRELOAD used this way isn't supported, because it overrides the linker's normal behaviour and force-loads the wrong libstdc++. Btw it probably would've worked if you preloaded libc too (bc in the original description you had the nixpkgs' older libc with archlinux's newer libstdc++)

I think we can close this now.

so in your case, it isn't even able to detect system's shared object, let alone Nix, I presume? But then, since you're on Arch, your system's and Nix's shared object must have a small version gap?

The gaps don't matter, what matters is that one must load libstdc++ at least as new as the one used at build/link time

What you're doing is still not a fix - it's merely a workaround

I'd say there's nothing to work around. LD_PRELOAD force-loads the wrong libstdc++ without a compatible libc, so it explicitly breaks the program deployed by nix.

Ashvith10 · 2024-02-10T11:07:26Z

@SomeoneSerge so my issue is different from @Brogolem35 's? At least from my perspective, it looks like I should open a new issue, as it is still not resolved.

SomeoneSerge · 2024-02-10T11:54:14Z

@Ashvith10 yes, your issue is different; it's not clear to me yet if there's anything to "fix" about it, but do consider opening an issue under the Nixpkgs repo regarding impure GIO libraries and libstdc++ mismatches

Also consider notifying Guix maintainers

SomeoneSerge · 2024-02-13T12:56:40Z

@Brogolem35 I updated the title to reflect how I understood the problem from your later comments. As mentioned above, I think this is a "wontfix" case. Thank you for reporting this, however, because this will help map the space of edge-cases and navigate people who encounter related errors

With that in mind, I'm closing the issue. Feel free to reopen if you think I misunderstood anything

* seems to fix the post run hook. more details in: NixOS/nixpkgs#287764

if you dont't pin the packages you get version `GLIBC_2.38' not found when trying to run the VM maybe related to NixOS/nixpkgs#287764 ?

SomeoneSerge mentioned this issue Nov 28, 2023

Any way for LD_LIBRARY_PATH to *not* break nix-env's absolute paths for dynamic libs NixOS/nix#902

Open

zimbatm transferred this issue from NixOS/nix Feb 10, 2024

Ashvith10 mentioned this issue Feb 11, 2024

libgioenvironment: loads the host system's (e.g. Guix's) libstdc++ #288042

Open

SomeoneSerge changed the title ~~Nix Package Manager on Arch Linux: "`GLIBC_2.38' not found" Error~~ hello: "`GLIBC_2.38' not found" when using LD_PRELOAD with the host system's libstdc++ (higher than nixpkgs') Feb 13, 2024

SomeoneSerge closed this as completed Feb 13, 2024

akshaykarle added a commit to sahajsoft/pii-detection-and-anonymizer that referenced this issue Apr 18, 2024

remove setting up LD_LIBRARY_PATH in CI setup

1f471d7

* seems to fix the post run hook. more details in: NixOS/nixpkgs#287764

Yeshey added a commit to Yeshey/nixos-nvidia-vgpu that referenced this issue Apr 26, 2024

Pinned all pkgs

1efede4

if you dont't pin the packages you get version `GLIBC_2.38' not found when trying to run the VM maybe related to NixOS/nixpkgs#287764 ?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

hello: "`GLIBC_2.38' not found" when using LD_PRELOAD with the host system's libstdc++ (higher than nixpkgs') #287764

hello: "`GLIBC_2.38' not found" when using LD_PRELOAD with the host system's libstdc++ (higher than nixpkgs') #287764

Brogolem35 commented Oct 22, 2023 •

edited

abathur commented Oct 22, 2023

Brogolem35 commented Oct 23, 2023

iFreilicht commented Oct 24, 2023

Brogolem35 commented Oct 24, 2023 •

edited

nixos-discourse commented Nov 6, 2023

SomeoneSerge commented Nov 6, 2023 •

edited

abathur commented Nov 6, 2023

SomeoneSerge commented Nov 6, 2023

nixos-discourse commented Nov 27, 2023

nixos-discourse commented Dec 20, 2023

cab404 commented Jan 14, 2024

t1endat commented Jan 19, 2024

SomeoneSerge commented Jan 19, 2024

Ashvith10 commented Feb 9, 2024

SomeoneSerge commented Feb 9, 2024

SomeoneSerge commented Feb 9, 2024 •

edited

Ashvith10 commented Feb 9, 2024

SomeoneSerge commented Feb 9, 2024

Ashvith10 commented Feb 9, 2024 •

edited

SomeoneSerge commented Feb 9, 2024

Ashvith10 commented Feb 9, 2024

SomeoneSerge commented Feb 9, 2024

Ashvith10 commented Feb 10, 2024

Ashvith10 commented Feb 10, 2024

SomeoneSerge commented Feb 10, 2024 •

edited

Brogolem35 commented Feb 10, 2024 •

edited

Ashvith10 commented Feb 10, 2024

SomeoneSerge commented Feb 10, 2024

Ashvith10 commented Feb 10, 2024

SomeoneSerge commented Feb 10, 2024 •

edited

SomeoneSerge commented Feb 13, 2024

hello: "`GLIBC_2.38' not found" when using LD_PRELOAD with the host system's libstdc++ (higher than nixpkgs') #287764

hello: "`GLIBC_2.38' not found" when using LD_PRELOAD with the host system's libstdc++ (higher than nixpkgs') #287764

Comments

Brogolem35 commented Oct 22, 2023 • edited

abathur commented Oct 22, 2023

Brogolem35 commented Oct 23, 2023

iFreilicht commented Oct 24, 2023

Brogolem35 commented Oct 24, 2023 • edited

nixos-discourse commented Nov 6, 2023

SomeoneSerge commented Nov 6, 2023 • edited

abathur commented Nov 6, 2023

SomeoneSerge commented Nov 6, 2023

nixos-discourse commented Nov 27, 2023

nixos-discourse commented Dec 20, 2023

cab404 commented Jan 14, 2024

t1endat commented Jan 19, 2024

SomeoneSerge commented Jan 19, 2024

Ashvith10 commented Feb 9, 2024

SomeoneSerge commented Feb 9, 2024

SomeoneSerge commented Feb 9, 2024 • edited

Ashvith10 commented Feb 9, 2024

SomeoneSerge commented Feb 9, 2024

Ashvith10 commented Feb 9, 2024 • edited

SomeoneSerge commented Feb 9, 2024

Ashvith10 commented Feb 9, 2024

SomeoneSerge commented Feb 9, 2024

Ashvith10 commented Feb 10, 2024

Ashvith10 commented Feb 10, 2024

SomeoneSerge commented Feb 10, 2024 • edited

Brogolem35 commented Feb 10, 2024 • edited

Ashvith10 commented Feb 10, 2024

SomeoneSerge commented Feb 10, 2024

Ashvith10 commented Feb 10, 2024

SomeoneSerge commented Feb 10, 2024 • edited

SomeoneSerge commented Feb 13, 2024

Brogolem35 commented Oct 22, 2023 •

edited

Brogolem35 commented Oct 24, 2023 •

edited

SomeoneSerge commented Nov 6, 2023 •

edited

SomeoneSerge commented Feb 9, 2024 •

edited

Ashvith10 commented Feb 9, 2024 •

edited

SomeoneSerge commented Feb 10, 2024 •

edited

Brogolem35 commented Feb 10, 2024 •

edited

SomeoneSerge commented Feb 10, 2024 •

edited