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.

Sign up for GitHub

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

Jump to bottom

third party packages install to lib/<arch> on focal #642

Open
flixr opened this issue Jun 17, 2021 · 7 comments · May be fixed by #689
Open

third party packages install to lib/<arch> on focal #642

flixr opened this issue Jun 17, 2021 · 7 comments · May be fixed by #689
Assignees
@nuclearsandwich

Comments

@flixr
Copy link
Contributor

flixr commented Jun 17, 2021

Hi,

I encountered an issue with third party packages on focal (at least for those using GNUInstallDirs): libraries are installed into /opt/ros/noetic/lib/x86_64-linux-gnu instead of just /opt/ros/noetic/lib (as in bionic).
This leads to the problem that other packages won't find these libs if this path is not added to e.g. LD_LIBRARY_PATH.

On bionic:

03:39:56 dh_auto_configure -- \
03:39:56 	-DCMAKE_INSTALL_PREFIX="/opt/ros/melodic" \
03:39:56 	-DCMAKE_PREFIX_PATH="/opt/ros/melodic"
03:39:56 	install -d obj-x86_64-linux-gnu
03:39:56 	cd obj-x86_64-linux-gnu && cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_PREFIX=/opt/ros/melodic -DCMAKE_PREFIX_PATH=/opt/ros/melodic

On focal:

03:40:19 dh_auto_configure -- \
03:40:19 	-DCMAKE_INSTALL_PREFIX="/opt/ros/noetic" \
03:40:19 	-DCMAKE_PREFIX_PATH="/opt/ros/noetic"
03:40:19 	install -d obj-x86_64-linux-gnu
03:40:19 	cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_AUTOGEN_VERBOSE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_INSTALL_PREFIX=/opt/ros/noetic -DCMAKE_PREFIX_PATH=/opt/ros/noetic ..

See e.g.
https://build.ros.org/job/Mbin_uB64__rcdiscover__ubuntu_bionic_amd64__binary/11/console
https://build.ros.org/job/Nbin_uF64__rcdiscover__ubuntu_focal_amd64__binary/4/console

This happens because of a change introduced in debhelper version 11.4 which explicitly sets CMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu in the configure step:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722697

This seems to only affect third party packages as there the generated debian rules has

export DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

Related issues:

Any thoughts on how to fix this?
One option could be to not set DEB_HOST_MULTIARCH for debhelper versions >= 11.4...
@flixr
Copy link
Contributor Author

flixr commented Jun 28, 2021

It seems that something similar was fixed with ros2/ros_workspace#20
@nuclearsandwich do you have any recommendation on how to proceed here?

@flixr
Copy link
Contributor Author

flixr commented Jun 28, 2021

Seems this was explicitly introduced in bloom to get shlibdeps working:
#600

@nuclearsandwich
Copy link
Contributor

Bloom behavior and our expectations have boomeranged a few times. Our goal is to match the expected behavior of the upstream platform and tooling.

I'm going to move this issue to Bloom for further discussion since the buildfarm is just executing package build scripts and all of the configuration for those builds should be done in bloom's templates.

@nuclearsandwich nuclearsandwich transferred this issue from ros-infrastructure/ros_buildfarm Jul 1, 2021
@nuclearsandwich
Copy link
Contributor

Bloom's default behavior should be to match the upstream platform defaults. It may be that with the debhelper changes, the ROS setup scripts provided by catkin in Noetic need to be updated to include the multiarch path in its load path the way that ros_workspace does for ROS 2.

@flixr flixr mentioned this issue Jul 15, 2021
Closed
@poggenhans
Copy link

@nuclearsandwich Actually it seems that this also affects normal ROS(2) packages (where DEB_HOST_MULTIARCH is not set), see also fzi-forschungszentrum-informatik/Lanelet2#162. Most catkin/ament packages ignore this variable and just install to lib, but it's actually a cmake best practice to use it.

I think it would make sense to explicitly overwrite CMAKE_INSTALL_LIBDIR in debian/rules, at least for catkin and ament packages, just to ensure everything is installed to lib, since this seems to be the ROS standard. I can also create a PR for this if desired.

The alternative would be to install all ROS packages according to the platform defaults, but that would require changing catkin_cmake_modules and ament_cmake and maybe break a lot of things (like nodelets assuming lib on ROS1).

@nuclearsandwich nuclearsandwich self-assigned this Sep 16, 2022
@nuclearsandwich
Copy link
Contributor

The alternative would be to install all ROS packages according to the platform defaults, but that would require changing catkin_cmake_modules and ament_cmake and maybe break a lot of things (like nodelets assuming lib on ROS1).

I think that it's quite likely that we may diverge between ROS 1 and ROS 2 on what to do. I think that ROS 1 should probably remain as is, possibly enforcing installation in lib for consistency whereas it I think it would make sense for ROS 2 to follow platform conventions.

The one immediate challenge for that is that the plain cmake bloom templates are common to ROS 1 and ROS 2 but we can customize the template behavior by checking the ROS distro version in the template logic. If you'd like to start a PR @poggenhans that'd be rad. I'll share the discussion with the rest of the infra team next week and see if there's any other thoughts on the matter.

poggenhans added a commit to poggenhans/bloom that referenced this issue Sep 18, 2022
@poggenhans
Set CMAKE_INSTALL_LIBDIR=lib in debian/control for ROS1 packages
4ee1f4b 
Newer debhelper versions will set CMAKE_INSTALL_LIBDIR=lib/<arch>.
This will cause packages that use GNUInstallDirs to install to this
location instead of lib and can confuse ROS tools.

closes ros-infrastructure#642
poggenhans added a commit to poggenhans/bloom that referenced this issue Sep 18, 2022
@poggenhans
Set CMAKE_INSTALL_LIBDIR=lib in debian/control for ROS1 packages
c890e3e 
Newer debhelper versions will set CMAKE_INSTALL_LIBDIR=lib/<arch>.
This will cause packages that use GNUInstallDirs to install to this
location instead of lib and can confuse ROS tools.

closes ros-infrastructure#642
@poggenhans poggenhans linked a pull request Sep 18, 2022 that will close this issue
Open
@poggenhans
Copy link

Ok, I created a PR that implements this. Looking forward for your feedback.

Also looking forward on the result of your discussion. Changing the library dir for all of ROS 2 to lib/<arch> sounds like a big deal to me. I'm not so deep into the details of ROS 2 compared to ROS 1, but I would still expect there to be a number of packages that assume things live in lib.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nuclearsandwich nuclearsandwich

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Set CMAKE_INSTALL_LIBDIR=lib in debian/control for ROS1 packages poggenhans/bloom
3 participants
@flixr @nuclearsandwich @poggenhans