Build fails when compiling against debug builds of gtsam

[ruffsl]

Looks like there is a linking issue with tbb when compiling against debug builds of gtsam:

overlay_ws> colcon build --symlink-install --mixin debug ccache
Starting >>> pcl_conversions
Starting >>> omnimapper
Starting >>> omnimapper_ros_msgs
Finished <<< pcl_conversions [0.49s]                                                                                                       
Starting >>> perception_pcl
Finished <<< perception_pcl [0.25s]                                                                                                    
Finished <<< omnimapper_ros_msgs [1.72s]                                                                 
--- stderr: omnimapper                             
libomnimapper.so: undefined reference to `vtable for tbb::task'
libomnimapper.so: undefined reference to `tbb::internal::allocate_root_with_context_proxy::allocate(unsigned long) const'
libomnimapper.so: undefined reference to `tbb::interface5::internal::task_base::destroy(tbb::task&)'
libomnimapper.so: undefined reference to `tbb::task_group_context::cancel_group_execution()'
libomnimapper.so: undefined reference to `tbb::task::note_affinity(unsigned short)'
libomnimapper.so: undefined reference to `typeinfo for tbb::task'
libomnimapper.so: undefined reference to `tbb::internal::allocate_additional_child_of_proxy::free(tbb::task&) const'
libomnimapper.so: undefined reference to `tbb::task_group_context::reset()'
libomnimapper.so: undefined reference to `tbb::internal::allocate_root_with_context_proxy::free(tbb::task&) const'
libomnimapper.so: undefined reference to `tbb::internal::allocate_additional_child_of_proxy::allocate(unsigned long) const'
libomnimapper.so: undefined reference to `tbb::task_group_context::init()'
libomnimapper.so: undefined reference to `tbb::task_group_context::~task_group_context()'
libomnimapper.so: undefined reference to `tbb::task_group_context::is_group_execution_cancelled() const'
libomnimapper.so: undefined reference to `tbb::internal::throw_exception_v4(tbb::internal::exception_id)'
collect2: error: ld returned 1 exit status
make[2]: *** [omnimapper_test] Error 1
make[1]: *** [CMakeFiles/omnimapper_test.dir/all] Error 2
make: *** [all] Error 2
---
Failed   <<< omnimapper	[ Exited with code 2 ]

Summary: 3 packages finished [5.14s]
  1 package failed: omnimapper
  1 package had stderr output: omnimapper
  1 package not processed

This is prevents the use of debug symbols to triage issues with the plane plugins. My guess that omnimapper is implicitly relying gtsam to export tbb during the linking stage, and that gtsam disables the use of tbb when the library is compiled using debug flags.

[BillWSY]

The error message here does not look related to GTSAM to me. Can you check if you link TBB correctly?

[ruffsl]

Can you check if you link TBB correctly?

That's thing, omnimapper's linking to TBB was being resolved implicitly given that GTSAM was linking to it already, except when building GTSAM with debug flags, this implicit relationship in CMake is broken. It seems that the TBB hasn't yet implemented a CMake-based build of TBB for easy embedding into open-source projects, despite large number of requests for it:
uxlfoundation/oneTBB#6

Thus it seems that GTSAM uses its own custom cmake files to find and link to TBB:
https://github.com/borglab/gtsam/blob/5cbb9dfd6c5bc6a38edd230fd0b9d9c7e5006b0b/cmake/FindTBB.cmake

Could we reuse that somehow without just duplicating the file in out repo, to ensure where linking to TBB the same exact way that a version/tag of gtsam is?

[BillWSY]

It is easier to copy the file to our repo.

The right thing to do would be, when GTSAM is installed, it should also install FindTBB. Which will be out of the scope that we can control.

[ruffsl]

Well, its non ideal given that its no longer certain that omnimapper will link to TBB in the same mannor as gtsam, if gtsam ever changes in the future, but 9e90715 should fix this for now.

[varunagrawal]

You could optionally turn off linking to TBB via CMake for debugging purposes. It should even make debugging easier.

[varunagrawal]

Also, I agree that TBB hasn't been easy to deal with. We've cleaned up a bunch of issues with TBB and GTSAM over the past few months, but still have various tasks items left. If you find anything helpful, we'd love to hear about it.