1

I try to create a Debian package for a program that depends on libcudart.so.6.0. The debuild script aborts with:

dpkg-shlibdeps: Fehler: Bibliothek libcudart.so.6.0 konnte nicht gefunden werden, benötigt von debian/myprog-cuda/usr/bin/myprog-cuda (ELF-Format: »elf64-x86-64«; RPATH: »«).
dpkg-shlibdeps: Fehler: Kann wegen des vorangegangenen Fehlers nicht fortfahren.
Hinweis: Bibliotheken werden nicht in anderen Binärpaketen, die keine Shlibs-oder Symboldatei haben, gesucht.
Um dpkg-shlibdeps dabei zu helfen, private Bibliotheken zu finden, könnte es notwendig sein, LD_LIBRARY_PATH zu setzen.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/myprog-cuda.substvars debian/myprog-cuda/usr/bin/myprog-cuda returned exit code 2
make: *** [binary-predeb-IMPL/myprog-cuda] Fehler 2
dpkg-buildpackage: Fehler: Fehler-Exitstatus von fakeroot debian/rules binary war 2
debuild: fatal error at line 1350:
dpkg-buildpackage -rfakeroot -D -us -uc failed

I think the equivalent english message is "couldn't find library libcudart.so.6.0 needed by debian/myprog-cuda/usr/bin/myprog-cuda". However, the path to that library is already in LD_LIBRARY_PATH.

If I start the dpkg-shlibdeps script manually, then I get a different error message:

$ dpkg-shlibdeps -Tdebian/myprog-cuda.substvars debian/myprog-cuda/usr/bin/myprog-cuda
dpkg-shlibdeps: Fehler: Keine Abhängigkeitsinformationen für /usr/local/cuda-6.0/targets/x86_64-linux/lib/libcudart.so.6.0 (verwendet von debian/myprog-cuda/usr/bin/myprog-cuda) gefunden.

This certainly means "no dependency information found for /usr/local/cuda-6.0/targets/x86_64-linux/lib/libcudart.so.6.0 (used by debian/myprog-cuda/usr/bin/myprog-cuda)"

I can fix this problem with

$ echo 'libcudart 6.0 cuda-core-libs-6-0' >debian/shlibs.local

Now, 'dpkg-shlibdeps' completes successfully, when I start in myself.

However, this does no affect 'debuild' - it still fails the same way it failed before. It seems that 'debuild' runs 'dpkg-shlibdeps' differently from me. Any idea how to track down or fix the problem?

|improve this question

migrated from stackoverflow.com Jul 27 '14 at 21:38

This question came from our site for professional and enthusiast programmers.

1

I had the same trouble with cuda 7.5 when I tried to build a package for the ROS framework with git-buildpackage. I updated your solution to 7.5 version and obtained the following:

echo 'libcudart 7.5 cuda-cudart-7-5' | sudo tee /var/lib/dpkg/info/cuda-cudart-7-5.shlibs
sudo chmod a+r /var/lib/dpkg/info/cuda-cudart-7-5.shlibs
echo '/usr/local/cuda/lib64' | sudo tee /etc/ld.so.conf.d/nvidia_settings.conf

To make it work I had to create an .shlibs file corresponding to cudart library in /var/lib/dpkg/info and add the path to cuda libraries in a .conf file in /etc/ld.so.conf.d/ .

|improve this answer
0

It seems that my local LD_LIBRARY_PATH setting is ignored by debuild. I can extend the global path:

echo 'libcudart 6.0 cuda-core-libs-6-0' | sudo tee /var/lib/dpkg/info/cuda-core-libs-6-0.shlibs
sudo chmod a+r /var/lib/dpkg/info/cuda-core-libs-6-0.shlibs

then it works.

This looks quite hacky. I'm still interested in a more clean solution.

|improve this answer
  • 1
    LD_LIBRARY_PATH is a runtime instruction to the linux OS about where to look for shared libraries that are required (i.e. linked-to) by a program when the program is launched. While it's remotely possible that a tool like debuild could inspect that environment variable, I doubt it does, and I don't think it would make sense for tools to condition their behavior on the current setting of LD_LIBRARY_PATH. I think you are confused about its intent. – Robert Crovella Jul 27 '14 at 16:35
  • Although your explanation makes sense, the error message and the manpage of dpkg-shlibdeps suggests, that it actually checks the LD_LIBRARY_PATH environment variable. – Lemming Jul 27 '14 at 18:43
  • Yes, it appears to use it, but note the text on the 14.04 manpage: "-ldirectory ... Note: Use this option instead of setting LD_LIBRARY_PATH, as that environment variable is used to control the run-time linker and abusing it to set the shared library paths at build-time can be problematic when cross-compiling for example. " So they recognize that depending on it for this purpose is "abusing" it, and is not the right way to go. Having said that, I don't know anything about your question or why it is or is not working. – Robert Crovella Jul 27 '14 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy