Humble Pinoccio package missing from latest sync

Benjamin-Tan · 2022-09-11T01:47:08.286Z

Thanks for the sync on ROS2 Humble! May I know is there any reason that a merged PR (e.g. pinocchio: 2.6.9-1 in 'humble/distribution.yaml' [bloom] by wxmerkt · Pull Request #34144 · ros/rosdistro · GitHub) has not been available on the release after the sync?

tfoote · 2022-09-12T06:53:32.022Z

Hi Benjamin,

It looks like your package is not currently successfully building due to a linking error.

You can see it’s failing to build and retrying approximately daily: Hbin_uJ64__pinocchio__ubuntu_jammy_amd64__binary [Jenkins]

The last build: Hbin_uJ64__pinocchio__ubuntu_jammy_amd64__binary #21 Console [Jenkins]

CMakeFiles/pinocchio_pywrap.dir/spatial/expose-inertia.cpp.o CMakeFiles/pinocchio_pywrap.dir/spatial/expose-motion.cpp.o CMakeFiles/pinocchio_pywrap.dir/spatial/expose-skew.cpp.o CMakeFiles/pinocchio_pywrap.dir/utils/conversions.cpp.o CMakeFiles/pinocchio_pywrap.dir/utils/dependencies.cpp.o CMakeFiles/pinocchio_pywrap.dir/utils/version.cpp.o -Wl,-rpath,/tmp/binarydeb/ros-humble-pinocchio-2.6.9/.obj-x86_64-linux-gnu/src:/opt/ros/humble/lib/x86_64-linux-gnu: ../../src/libpinocchio.so.2.6.9 /opt/ros/humble/lib/x86_64-linux-gnu/libeigenpy.so /usr/lib/x86_64-linux-gnu/libboost_python310.so /usr/lib/x86_64-linux-gnu/libboost_filesystem.so /usr/lib/x86_64-linux-gnu/libboost_system.so -lurdfdom_sensor -lurdfdom_model_state -lurdfdom_model -lurdfdom_world /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.1.0 /opt/ros/humble/lib/x86_64-linux-gnu/libhpp-fcl.so /usr/lib/x86_64-linux-gnu/libboost_serialization.so /usr/lib/x86_64-linux-gnu/libboost_chrono.so /opt/ros/humble/lib/x86_64-linux-gnu/liboctomap.so.1.9.8 /opt/ros/humble/lib/x86_64-linux-gnu/liboctomath.so.1.9.8 **18:14:36** clang: error: unable to execute command: Killed **18:18:32** clang: error: linker command failed due to signal (use -v to see invocation) **18:18:32** make[4]: *** [bindings/python/CMakeFiles/pinocchio_pywrap.dir/build.make:867: bindings/python/pinocchio/pinocchio_pywrap.cpython-310-x86_64-linux-gnu.so.2.6.9] Error 254 **18:18:33** make[4]: Leaving directory '/tmp/binarydeb/ros-humble-pinocchio-2.6.9/.obj-x86_64-linux-gnu' **18:18:33** make[3]: *** [CMakeFiles/Makefile2:1758: bindings/python/CMakeFiles/pinocchio_pywrap.dir/all] Error 2 **18:18:33** make[3]: Leaving directory '/tmp/binarydeb/ros-humble-pinocchio-2.6.9/.obj-x86_64-linux-gnu' **18:18:33** make[2]: *** [Makefile:149: all] Error 2 **18:18:33** make[2]: Leaving directory '/tmp/binarydeb/ros-humble-pinocchio-2.6.9/.obj-x86_64-linux-gnu' **18:18:33** dh_auto_build: error: cd .obj-x86_64-linux-gnu && make -j1 VERBOSE=1 returned exit code 2 **18:18:33** make[1]: Leaving directory '/tmp/binarydeb/ros-humble-pinocchio-2.6.9' **18:18:33** make[1]: *** [debian/rules:46: override_dh_auto_build] Error 25 **18:18:33** make: *** [debian/rules:30: build] Error 2

It’s emailing the indicated maintainers for each failed build (see the end of the build log), but based on reading the email addresses it doesn’t look like you’re listed as a maintainer so you haven’t received the notifications.

If I remember correctly compiling and linking pinocchio takes a lot of resources and has been a problem in the past. This may be depleting the build machines memory.

Benjamin-Tan · 2022-09-12T07:48:37.062Z

Hi Tully, thanks for the insights! really appreciate that. Under normal circumstances, how could this be resolved since it takes a lot of resources?

tfoote · 2022-09-12T08:25:15.031Z

The first order of business is to make sure to avoid potential parallelization.

However to address this more directly the first thing that can be considered is to make find ways that compile objects can be made smaller. As well there is a significant improvements available from doing things like auditing include orders and leveraging forward declarations instead of requiring full definitions and linking of objects. This is often overlooked in template heavy libraries but is just as important there as in classic libraries.

The PCL project (another heavily templated library) ran into this problem back about a decade ago, and with a close look at their project structure was able to reduce compile time resources by an order of magnitude without changing the API at all.

wxm · 2022-10-16T16:37:57.102Z

Hi @Benjamin-Tan
Many thanks for flagging this up. We have reduced the amount of debug symbols in the build and this has resolved this issue (Hbin_uJ64__pinocchio__ubuntu_jammy_amd64__binary [Jenkins]). The package should be available with the next sync.

olivier-stasse · 2022-10-16T16:59:20.765Z

Thanks @wxm for fixing the issue.

Benjamin-Tan · 2022-10-17T01:39:19.548Z

Thanks @wxm for the fix!