statically linked roscpp

asked 2017-04-12 02:17:52 -0500

ahendrix gravatar image

I'm working on a small system and I'm trying to optimize the build and distribution process for roscpp by statically linking it.

As a sample, I'm trying to run the topic_tools relay node, and I'm finding that it crashes during shutdown. I've run it in GDB, and I found that because the entire executable is statically linked with roscpp, the ros::TopicManager instance is destructed before the global ros::Publisher object in the relay node, and then the ros::Publisher destructor tries to access the ros::TopicManager singleton, and crashes because that object has already been destructed.

If I build roscpp as a shared library and link to it dynamically, the symbol dependencies between the various dynamic libraries (roscpp, rosconsole, rostime, etc) result in proper destruction order, and I don't encounter this bug.

I'm using a proprietary build system, so catkin and cmake-related questions or suggestions are not useful.

Has anyone encountered this before, and do you have any advice on fixing it?

edit retag flag offensive close merge delete


The only thing I can think of is to check the order of initialization for static members. The global objects in your main file maybe getting destroyed after the ones in roscpp due to the initialization order. The shared library loading/unloading might have changed the order so that it was safe.

William gravatar image William  ( 2017-04-12 15:40:34 -0500 )edit

@William: yep, that's exactly what I'm seeing. Since the globals in ROS are in a different translation unit from my main, there isn't a standard way to enforce the relative initialization order.

ahendrix gravatar image ahendrix  ( 2017-04-12 16:06:30 -0500 )edit