Skip to content
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

Building from source with Humble results in incorrect include directory #246

Closed
Mark-Beaty opened this issue Jan 12, 2023 · 1 comment
Closed

Comments

@Mark-Beaty
Copy link

When this package is built with ROS2 Humble from source (specifically on the Orin AGX with Ubuntu 20.04 and Jetpack 5.0.2), the includes ends up located at /opt/ros/humble/install/include/pluginlib/pluginlib/* rather than at /opt/ros/humble/install/include/pluginlib/*. This breaks imports which are used in the provided files. I specifically ran into issues with importing pluginlib/class_loader.hpp with another package, which failed and said that the file couldn't be found. After changing my include to pluginlib/pluginlib/class_loader.hpp, the error changed to reference when class_loader.hpp was attempting the import for pluginlib/class_desc.hpp which cannot be found.

I believe this is likely due to some changes/differences with CMakeList.txt which exist on the Humble branch but are significantly different on the Foxy branch. My packages were able to successfully utilize pluginlib before migrating from ROS Foxy, and I can't directly speak to how this installation looks when installed with APT packages, but the solution looks to be as simple removing the extra nested pluginlib directory from the /opt/ros/humble/install/include folder. I don't know enough about CMakeLists.txt structuring to know how to propose a true solution. If there's any other useful info I can provide let me know and I'm happy to provide it.

@Mark-Beaty
Copy link
Author

I found the solution to my issue, it was actually not related to pluginlib but to my plugin package not having pluginlib in the ament_target_dependencies. This was unchanged from a Foxy implementation that was working, so I'm unsure why I didn't encounter this error earlier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant