| 1 Aug 2024 |
 yorickvp | all I can find is the line
-- Looking for a CUDA host compiler - /nix/store/vk12rv84vs98bv3wi4jgbpi59lrs3ymj-gcc-wrapper-12.3.0/bin/c++
in the build logs | 14:34:20 |
| yorickvp | okay, that would be because setup-cuda-hook sets that. but it does have -L/nix/store/bn7pnigb0f8874m6riiw6dngsmdyic1g-gcc-13.3.0-lib/lib -L/nix/store/kzx58d5pbb78gnv9s4d62f4r46x9waw9-gcc-12.3.0-lib/lib | 14:44:23 |
 SomeoneSerge (utc+3) | Are you using multiple nixpkgs revisions? | 14:46:52 |
| SomeoneSerge (utc+3) | Ah, no, I guess the second one is propagated by something else | 14:47:07 |
| SomeoneSerge (utc+3) | -L/nix/store/bn7pnigb0f8874m6riiw6dngsmdyic1g-gcc-13.3.0-lib/lib looks correct | 14:47:15 |
| yorickvp | nixpkgs c66e984bda09e7230ea7b364e677c5ba4f0d36d0 | 14:47:21 |
| SomeoneSerge (utc+3) | In reply to @yorickvp:matrix.org
all I can find is the line
-- Looking for a CUDA host compiler - /nix/store/vk12rv84vs98bv3wi4jgbpi59lrs3ymj-gcc-wrapper-12.3.0/bin/c++
in the build logs This is the compiler | 14:47:39 |
| SomeoneSerge (utc+3) | * This is the compiler, the libstdc++ should be from gcc13 | 14:47:52 |
| yorickvp | $ cat /nix/store/vk12rv84vs98bv3wi4jgbpi59lrs3ymj-gcc-wrapper-12.3.0/nix-support/cc-ldflags
-L/nix/store/zc0nsv23pakbafngjy32kvhfzb16as43-gcc-13.3.0/lib/gcc/x86_64-unknown-linux-gnu/13.3.0 -L/nix/store/bn7pnigb0f8874m6riiw6dngsmdyic1g-gcc-13.3.0-lib/lib -L/nix/store/kzx58d5pbb78gnv9s4d62f4r46x9waw9-gcc-12.3.0-lib/lib
| 14:48:08 |
| SomeoneSerge (utc+3) | Yeah the way we worked around cc-wrapper was kind of ugly and relied on gcc respecting priorities/a particular order of flags | 14:51:55 |
| SomeoneSerge (utc+3) | I'd rather guess that gcc12\s libstdc++ comes from elsewhere, like another dependency. Run with LD_DEBUG=libs | 14:52:22 |
| SomeoneSerge (utc+3) | In reply to @ss:someonex.net
Yeah the way we worked around cc-wrapper was kind of ugly and relied on gcc respecting priorities/a particular order of flags (yes this is bad and we should fix that) | 14:52:47 |
| yorickvp | run what with LD_DEBUG=libs? | 14:53:06 |
| SomeoneSerge (utc+3) | like
$ LD_DEBUG=libs python
import torch
| 14:53:26 |
| SomeoneSerge (utc+3) | * like
$ LD_DEBUG=libs python
import torch
# do whatever you do
| 14:53:34 |
| SomeoneSerge (utc+3) | * like
$ LD_DEBUG=libs python my-repro.py
| 14:53:51 |
| yorickvp | alright, I'll try that | 14:54:17 |
| yorickvp | the failing line is LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${cudaPackages.cuda_cudart.stubs}/lib python -m pybind11_stubgen -o . bindings | 14:55:02 |
| yorickvp | In reply to @ss:someonex.net
like
$ LD_DEBUG=libs python my-repro.py
okay, so my libraries have rpath $ORIGIN:/home/yorick/outputs/out/lib:/nix/store/kzx58d5pbb78gnv9s4d62f4r46x9waw9-gcc-12.3.0-lib/lib:/nix/store/8rzflwd9bxri4s0bpicm8bkmi2ikmv7n-nccl-2.21.5-1/lib:/nix/store/61q201jxc1g6pkbvhyyriwlm7zasa81k-openmpi-4.1.6/lib:/nix/store/g798k855fny946jnycp61vkzy27kwlyl-libcublas-12.1.3.1-lib/lib:/nix/store/dbwp0scbb0rk78m636sb7cvycz8xzgyh-glibc-2.39-52/lib:/nix/store/bn7pnigb0f8874m6riiw6dngsmdyic1g-gcc-13.3.0-lib/lib:/nix/store/2v1jx43nsp9njldxh4bfljvh5wmnbzk3-python3.10-tensorrt-cu12-libs-10.2.0/lib/python3.10/site-packages/tensorrt_libs:/nix/store/ybqfab6p2p6ir9dcr6gn6rxn825wb86g-cudnn-8.9.7.29-lib/lib | 15:12:20 |
| yorickvp | looks like cmake is writing it as a LINK_PATH | 15:22:52 |
| SomeoneSerge (utc+3) | So there's something else propagating an unwrapped (differently wrapped) gcc12 maybe | 15:23:40 |
| yorickvp | how can I list all propagated inputs? | 15:24:08 |
| SomeoneSerge (utc+3) | all propagated inputs of | 15:24:30 |
| yorickvp | I'm in a nix develop for the drv that produces the libraries with the wrong rpath | 15:25:24 |
| SomeoneSerge (utc+3) | H'mm, maybe you can echo "${pkgsBuildHost[@]}" for compilers/build tools | 15:26:51 |
| SomeoneSerge (utc+3) | But that won't tell you where it's coming from | 15:27:09 |
| SomeoneSerge (utc+3) | Just do a nix-tree --derivation or path-info why-depends | 15:27:31 |
| yorickvp | seems like there's no unwrapped gcc | 15:48:59 |
| yorickvp | libtorch_cuda.so also manages to link it | 15:49:53 |
| yorickvp | https://gist.github.com/yorickvP/b263b9d6d058280a3f7d4c70eff2a758
/nix/store/mbg29pcjydgss24z0v6jczjda7q4z9x6-gcc-12.3.0.drv (the offending gcc lib) only occurs as a dependency of the gcc-wrapper that has the correct lib first | 15:54:09 |
