cudaPackages_12.cudatoolkit: hotfix after switching to autoPatchelfHook #224986
Conversation
|
Result of 11 packages failed to build:
52 packages built:
|
|
Since I broke both |
SomeoneSerge
force-pushed
the
cudatoolkit-autopatchelf-followup
branch
from
361abc3
to
6dcf460
Compare
|
Just tested it. Seems to work 😊 |
| ${lib.optionalString (lib.versionAtLeast version "11.8") | ||
| # error: auto-patchelf could not satisfy dependency libtiff.so.5 wanted by /nix/store/.......-cudatoolkit-12.0.1/host-linux-x64/Plugins/imageformats/libqtiff.so | ||
| # we only ship libtiff.so.6, so let's use qt plugins built by Nix. | ||
| # TODO: don't copy, come up with a symlink-based "merge" | ||
| '' | ||
| rsync ${lib.getLib qt6Packages.qtimageformats}/lib/qt-6/plugins/ $out/host-linux-x64/Plugins/ -aP | ||
| ''} |
There was a problem hiding this comment.
I'm not sure I follow the logic of this comment... how does using Qt plugins built by nix alleviate the .so.5 vs .so.6 version issue?
Also, why use rsync instead of simply ln -s? Ideally we'd like to avoid copying files b/w outputs.
There was a problem hiding this comment.
how does using Qt plugins built by nix
...because Nix builds Qt plugins against nixpkgs' libtiff and they end up linking to .so.6
Also, why use rsync instead of simply ln -s? Ideally we'd like to avoid copying files b/w outputs.
No good reason at all, other than I wanted a "synchronize these two directory trees recursively" operation, and rsync is one. Either way, we want to be removing all of these plugins, and for all versions of cuda, so we'll have rewritten this patch before we can close #224646
SomeoneSerge
force-pushed
the
cudatoolkit-autopatchelf-followup
branch
from
5d0d4c8
to
b100b0a
Compare
|
@samuela yup, let's go |
Description of changes
"Regression" introduced in #178440, I forgot to test
cudaPackages_12Error reported in the comment: #224646 (comment)
I had to do something ugly about the qt dependencies, because NVidia builds against an out-of-date libtiff which we haven't got. Once we have a proper solution to #224646 we can remove that hack from the
installPhase. Obviously, we need to verify if we this work at runtime as well.For more context: this errors shows that
cudaPackages_12.cudatoolkitandcudaPackages_11_8.cudatoolkithave technically always been "broken", since they shipped executables and/or libraries that weren't properly patchelf-ed. What #224646 changes is that this kind of omissions cannot go unnoticedThe legacy
cudaPackages.cudatoolkitgetting uglier is also "OK": one more reason to migrate to the redistcudaPackages.{cuda_,lib}*CC @aaronmondal CC @NixOS/cuda-maintainers
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)