On Tue, 2023-03-14 at 09:50 +0200, Andrius Merkys wrote:
On 2023-03-14 09:25, Andrius Merkys wrote:
dpkg-shlibdeps: error: no dependency information found for
/lib/x86_64-linux-gnu/libcudnn.so.8 (used by
debian/libtorch1.13/usr/lib/x86_64-linux-gnu/libtorch_python.so.1.13)
Hint: check if the library actually comes from a package.
Right, /lib/x86_64-linux-gnu/libcudnn.so.8 does not come from a package,
it is downloaded and installed without ownership by nvidia-cudnn.
I see that nvidia-cudnn runs the downloader in postinst. Why the
downloaded libraries are not transformed into a source package instead?
It would seem a bit more natural to me, even if the source package would
contain non-rebuilt binaries.
Note this is non-free blob. cudnn has a different EULA than CUDA toolkit or
anything alike. The cudnn is problematic enough to upload onto non-free.
I have already tried to upload the cudnn binaries with the
EULA and without doubt, the binaries are not even suitable for non-free.
And the cudnn binaries for the three architectures, amd64 ppc64el arm64
is a ~3 GB upload. Stripping debugging symbols is forbidden as per EULA.
Alternatively, dpkg-shlibdeps could be instructed to ignore nvidia-cudnn
libraries, I guess.
Anyway, the installation target is broken and needs a fix. I'll look into
my installer script for nvidia-cudnn, but I'm really unable to work on
the pytorch-cuda install now.