rclcpp add NO_UNDEFINED_SYMBOLS to rclcpp_components_register

this adds an option NO_UNDEFINED_SYMBOLS to the rclcpp_components_register_node cmake macro, which adds the required linker option to the (component library) target to deny undefined symbols.

Undefined symbols usually produce an error if an executable is built, but due to the way the autogenerated executable generated by rclcpp_components_register_node is constructed, that doesn't happen here, and the error occurs only when executing it. This change makes this a link-time error again.

This is especially intended for the workflow of migrating a ros node which was built directly as an executable before to using rclcpp_components_register_node.

By default, the option is disabled. If no adverse impact is detected, i suggest enabling it by default in a future release.

fixes #2744

Feb 14 '25 17:02 ottojo

I wonder if we should also use --no-allow-shlib-undefined?

Feb 14 '25 18:02 mjcarroll

I wonder if we should also use --no-allow-shlib-undefined?

Reading an article on this in the gentoo wiki, it seems this would be useful here, as long as there are no symbols that would only be provided by the container which loads the component. I did a quick test, and it seems that this is not the case, but i'm not very familiar with the plugin mechanism under the hood.

Feb 18 '25 17:02 ottojo

I'm not sure whether --no-allow-shlib-undefined should be included because I can't find docs for it, but approving because the code LGTM!

the ld(1) man page has docs:

       --no-allow-shlib-undefined
           Allows or disallows undefined symbols in shared libraries.
           This switch is similar to --no-undefined except that it
           determines the behaviour when the undefined symbols are in a
           shared library rather than a regular object file.  It does not
           affect how undefined symbols in regular object files are
           handled.

           The default behaviour is to report errors for any undefined
           symbols referenced in shared libraries if the linker is being
           used to create an executable, but to allow them if the linker
           is being used to create a shared library.

           The reasons for allowing undefined symbol references in shared
           libraries specified at link time are that:

           •   A shared library specified at link time may not be the
               same as the one that is available at load time, so the
               symbol might actually be resolvable at load time.

           •   There are some operating systems, eg BeOS and HPPA, where
               undefined symbols in shared libraries are normal.

               The BeOS kernel for example patches shared libraries at
               load time to select whichever function is most appropriate
               for the current architecture.  This is used, for example,
               to dynamically select an appropriate memset function.

Feb 24 '25 09:02 ottojo

Pulls: ros2/rclcpp#2746 Gist: https://gist.githubusercontent.com/mjcarroll/a775e3c08b1a3c3ba2cec2f57da3734b/raw/69fb337a12405174b2594fe2a6f53629d137c83d/ros2.repos BUILD args: TEST args: ROS Distro: rolling Job: ci_launcher ci_launcher ran: https://ci.ros2.org/job/ci_launcher/15300

Linux
Linux-aarch64
Linux-rhel
Windows

Mar 06 '25 21:03 mjcarroll

Linux
Linux-aarch64
Linux-rhel
Windows

Mar 07 '25 11:03 ahcorde

Pulls: ros2/rclcpp#2746 Gist: https://gist.githubusercontent.com/ahcorde/9fb08b36a3b4cb4c6b84cd333e4908ba/raw/a8bb491b6cb1447ab79120b2b88ccd0136c0d290/ros2.repos BUILD args: --packages-above-and-dependencies rclcpp TEST args: --packages-above rclcpp ROS Distro: jazzy Job: ci_launcher ci_launcher ran: https://ci.ros2.org/job/ci_launcher/15305