statically linked roscpp
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?
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
roscppdue to the initialization order. The shared library loading/unloading might have changed the order so that it was safe.@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.