-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cudaPackages.backendStdenv: mismatch with stdenv causes libstdc++ errors #220341
Comments
I've encountered similar issues while trying to use |
Hi @blurgyy can you post the error logs from these failures? |
This
|
Sure @samuela, here are the logs:
edit: |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tweag-nix-dev-update-45/26397/1 |
Ok, so I've no idea what's happening, but I'm looking at:
This appears to mean that ❯ objdump -T /nix/store/yiflcg7zmirny3654g8l8f85sz958gqk-gcc-11.3.0-lib/lib/libstdc++.so.6 | rg 'GLIBCXX_3.4.30
❯ objdump -T '/nix/store/hvs05k932v31cfckv49nx1pin0qjd20v-python3.10-scipy-1.10.1/lib/python3.10/site-packages/scipy/optimize/_highs/_highs_wrapper.cpython-310-x86_64-linux-gnu.so' | rg GLIBCXX_3.4.3
0000000000000000 DF *UND* 0000000000000000 (GLIBCXX_3.4.30) _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE It would seem that libstdc++ is DT_NEEDED for scipy-whatever-wrapper:
And it expects to get it from
We can see that
Could it be that when python the interpreter dlopen's jaxlib the symbols from libstdc++ found through jaxlib's runpath end up in some uhghh process-global namespace, and that by the time python dlopen's scipy it already ignores all the look ups for libstdc++? Frankly, I can't say I understand the mechanics too well |
Ideally, we'd also have means to automatically check (assert/warn) whether we're trying to use runtime dependencies that want an incompatible libstdc++. In the first approximation we could add |
Another failure: |
Cf. # pkgs/top-level/all-packages.nix
inherit (let
num =
if (with stdenv.targetPlatform; isVc4 || libc == "relibc") then 6
else 12;
numS = toString num;
in {
gcc = pkgs.${"gcc${numS}"};
gccFun = callPackage (../development/compilers/gcc + "/${numS}");
}) gcc gccFun;
gcc-unwrapped = gcc.cc; I don't want to, but we could add a conditional there, checking |
IIRC stdenv's GCC is gcc12 and cudaPackages_12 is also gcc12... could we fix these errors by upgrading cudaPackages to cudaPackages_12? |
Yes, that'd solve it for as long as until the next gcc major release. We've been waiting for pytorch: #222778 Maybe we can already start running tests |
@ConnorBaker I think we can rename the issue into something more discoverable: "cudaPackages.backendStdenv causes libstdc++ mismatch errors when lagging behind |
stdenv
causes libstdc++
errors
stdenv
causes libstdc++
errors
Is anyone able to confirm if #224150 stems from the same issue? Xgboost with R+CUDA support fails near the end on:
The GLIBCXX_3.4.30 version appears to match up with what's discussed here. |
Of the "big" packages, only jax is still failing: https://hercules-ci.com/github/SomeoneSerge/nixpkgs-unfree/jobs/3864 |
Hmm, IIUC #223664 was intended to fix this issue, and it seems it's been largely successful. Any idea why it's working on all packages except JAX? |
@samuela it would appear that our jedi tricks aren't sufficient to force bazel into using the correct libstdc++ version, and I'm pretty sure this isn't unrelated to us using I have a suspicion that we're observing an instance of #225493, which is why I filed it right now. In fact, I'm pretty certain: if all Maybe we could verify this by... adding |
Looking at https://hercules-ci.com/github/SomeoneSerge/nixpkgs-cuda-ci/jobs/4343, I don't think there are any libstdc++ related build errors left. Any future problems should probably be tracked in #226165 |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/cuda-team-roadmap-update-2023-08-29/32379/1 |
Describe the bug
Per #218265 (comment), when using CUDA-enabled
scipy
it is possible to run intolibstdc++.so.6: version 'GLIBCXX_3.4.30' not found
errors.Historically the fix for this problem has been to ensure the derivations of CUDA-enabled packages use a compiler compatible with the version of NVCC being used, instead of the default compiler provided by
stdenv
.Additional context
This is a followup from #218265.
Notify maintainers
@NixOS/cuda-maintainers
The text was updated successfully, but these errors were encountered: