-
Notifications
You must be signed in to change notification settings - Fork 46
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
Torch shared library: libc10.so: cannot open shared object file #639
Comments
I'm not sure how colcon could do any of this differently. How would you expect this project to build without colcon involved at all? It seems like the root of your problem is that Torch is installed to your home directory and your environment variables are not updated to enable discoverability from that location. This would all happen (presumably by pip) prior to building the package at all, whether colcon is involved or not. Is there a system package for Torch you could use instead? |
Hi @cottsay ! For example this is the colcon log when I compile online_traj:
In the linking step I can see the correct links to the .so files that are missing in the final exe (e.g. Another test I tried is to launch the last c++ command from the log above, inside
which correctly creates the exe online_traj in the same folder.
Even sourcing the ROS2 workspace doesn't seem to work with the exe under
|
It seems that the mechanism by which Torch wants you to locate the shared libraries is using an RPATH on your binaries. CMake is likely stripping RPATHs during installation, as is the default behavior on most platforms. These RPATHs are an embedded path in the binary that lets the runtime library loader know about additional locations to look for dynamic libraries. That's why manually creating the executable seems to "work" - the RPATHs haven't yet been stripped by CMake. RPATHs are pretty controversial. Many developers swear by them and sometimes require them when building their software. Platform maintainers, on the other hand, often forbid absolute RPATHs. Major distributions like Debian, Ubuntu, and Fedora discourage their use for a variety of reasons. There are valid reasons on both sides that we won't get into here. Since Torch has forced your hand, you'll need to instruct CMake to include at least some RPATHs at install time. The most notable downside here is that the binaries you create will no longer be portable, meaning that they'll only be able to find the Torch libraries if they're located exactly where you have them when you build your package. ROS workspaces are generally portable, meaning that you can move the workspace to a different location and re-source the Again, this is nothing to do with colcon, so this really isn't an appropriate form to troubleshoot your issue. Help requests like this for ROS packages should really be discussed on discourse.ros.org. |
Thank you @cottsay for the explanation. I will try to better understand how to manage the RPATH with CMake. |
Hi all,
I created a ROS2 Humble C++ package which includes
<torch/script.h>
on my Orin NX (aarch64).I think I correctly managed the CMakeList.txt and package.xml but I cannot run the package if I don't set the LD_LIBRARY_PATH manually first.
As a workaround I can add
/home/nvidia/.local/lib/python3.8/site-packages/torch/lib/
but I'd preferinstall/setup.bash
to find them instead.As
ldd
shows, the .so files from libtorch are missing:This is my current CMakeLists.txt
All the missing libs are in
/home/nvidia/.local/lib/python3.8/site-packages/torch/lib/
The text was updated successfully, but these errors were encountered: