-
-
Notifications
You must be signed in to change notification settings - Fork 36
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
Using a system library #200
Comments
Solving this would also deal with #180. |
In general, making sure that it is not possible to find system libraries is a desirable property, as in general apt packages and conda packages may use different versions (with different ABIs) of the same libraries, and mixing them can lead to runtime crashes that are quite hard to debug. In the quite rare case of a system library that can be cleanly used (typically if it is a library without any dependency, but even in that cases there could be problems), cmake needs to be pointed to the library to use using the canonical way to let CMake aware of where a package is, that depends on how the package is found. To help you, it is probably easier if you:
|
@traversaro thanks for the information. I have dug a more in the CMake documentation and I find the way to make it work. Now to answer your question there are two low level hardware interfaces that I have tried to work with on Raspberry Pi: wiringPi and pigpio. They both have very convoluted ways of installing, for instance Now, the way I had the CMakeLists.txt to work was to use: find_library(PIGPIO_LIB pigpiod_if2 REQUIRED)
find_path(PIGPIO_INCLUDEDIR pigpiod_if2.h REQUIRED) to find them and then to use them: target_link_libraries(trilobot_hardware
${PIGPIO_LIB}
)
target_include_directories(trilobot_hardware PUBLIC
${PIGPIO_INCLUDEDIR}
${CMAKE_CURRENT_SOURCE_DIR}/include
) That seems to be doing the trick and would also work if the libraries are installed in different directories (ex. |
Ok, thanks for the info! |
Solution to issue cannot be found in the documentation.
Issue
The context is very simple: a robot using a Raspberry Pi (Bookworm) with ROS2 installed in a Conda/Mamba environment that needs to access GPIO, I2C, etc. (like you would expect from a robot).
If you use Python, it's not a big issue: as long as the packages are available in Conda-Forge or even PyPi you can install over in the environment and then use them in the ROS package.
The problem is when you try to write C++ packages (for instance when using
ros2_control
. If there are no Conda packages (very likely as there are a lot of system specific requirements tailored for the physical machine) you might only have the option of installing libraries withapt
. If the ROS installation is on an Ubuntu system from Debian packages, that seems to be no problem (see this package for instance): your C++ packages could use the system libraries as any other package.But that does't happen in a Conda environment. The
apt
installed libraries can't seemed to be found by theament-cmake
(or at least I could not find a way to cleanly do this).The only way I could work around this (and is very ugly) is to explicitly include full path. For instance the CPP file will include:
and the
CMakeLists.txt
would link:It works, but it is very ugly and very possible would create problems of porting.
Do you have any idea how this can we dealt with in a more elegant way? Like creating a "link library" in the conda environment, or even a ROS package that mirrors the include and the libraries from the system?
Thanks.
Installed packages
Environment info
The text was updated successfully, but these errors were encountered: