TLS definition mismatch

[parkerlreed]

Description

When trying to compile rtabmap, linking fails due to gtsam metis and system metis mismatch

Steps to reproduce

1. Install gtsam from master
2. Compile rtabmap

Environment

Arch Linux
gcc 9.2.0
metis 5.1.0
rtabmap from master
gtsam from master

Additional information

gtsam compiled with

  cmake -DCMAKE_INSTALL_PREFIX=/usr -DGTSAM_USE_SYSTEM_EIGEN=ON -DGTSAM_BUILD_EXAMPLES_ALWAYS=OFF -DGTSAM_BUILD_TESTS=OFF -DGTSAM_BUILD_UNSTABLE=OFF ..

/usr/bin/ld: gk_cur_jbufs: TLS definition in /usr/lib/libgtsam_metis.so section .tdata mismatches non-TLS definition in /usr/lib/libmetis.so section .data
/usr/bin/ld: /usr/lib/libmetis.so: error adding symbols: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [app/src/CMakeFiles/rtabmap.dir/build.make:265: ../bin/rtabmap] Error 1
make[2]: Leaving directory '/home/parker/build/rtabmap/build'
make[1]: *** [CMakeFiles/Makefile2:930: app/src/CMakeFiles/rtabmap.dir/all] Error 2
make[1]: Leaving directory '/home/parker/build/rtabmap/build'
make: *** [Makefile:152: all] Error 2

If the error may be within rtabmap, please let me know and I will file a bug over there.

[mikesheffler]

Hi, @parkerlreed . A few things:

1. Try building develop for GTSAM. That's what is considered to be the default branch (I'm not sure where master is, but, at the very least, it's waaaaay behind develop).

2. If things remain squirrely. you can try building one of the 4.x.x tags to help one of the CMake ninjas (like @jlblancoc ) help you, but I think this falls outside of the realm of gtsam problems. I'm not sure anyone is building in Arch, but I'm also not sure what the nightly builds are built against nowadays.

3. I think TLS in this context is referring to thread-local storage. Is there anything interesting about your build? How about disabling (or enabling) thread building blocks?

4. Are you aware that you can choose whether or not GTSAM builds the version of metis it ships with? I'm pretty sure you can use the 'system' metis, which is probably your only prayer if metis data is actually going across an rtabmap -> gtsam boundary.

Hopefully, just building develop and trying to coax the build into using the system metis will work. :)

[parkerlreed]

Thanks! Will give it a try.

I also just noticed the packaging I am using sets an explicit rename for gtsam's metis. If develop doesn't work out, I will follow up with that change.

https://aur.archlinux.org/cgit/aur.git/tree/rename-included-libmetis.patch?h=gtsam-git

[parkerlreed]

Just realized I was already using develop as that is default :) Had that mixed up in my head.

I will try the flag to use the system metis and see how that goes.

[parkerlreed]

I see a cmake flag for the metis executables but seemingly nothing for telling it to use system metis. Do you know what that flag may be?

gtsam/gtsam/3rdparty/CMakeLists.txt

Line 51 in 8212cb2

option(GTSAM_BUILD_METIS_EXECUTABLES "Build metis library executables" OFF)

[mikesheffler]

Just realized I was already using develop as that is default :) Had that mixed up in my head.

I figured. It's marked as the default branch, but people do build master now and then :)

I see a cmake flag for the metis executables but seemingly nothing for telling it to use system metis. Do you know what that flag may be?

I'm unsure of the actual plumbing, but, using qtcreator as my IDE, it has a CMake thing built-in that is pretty similar to cmake-gui. In the list of stuff, I see GTSAM_BUILD_METIS_EXECUTABLES (it is disabled in my build), and I believe that means that I am using system metis stuff.

If I understand correctly, GTSAM_BUILD_METIS_EXECUTABLES is bubbling up from /gtsam/3rdparty/CMakeLists.txt.

I also see that /gtsam/3rdparty/Eigen/MetisSupport has #include <metis.h>, so GTSAM_USE_SYSTEM_EIGEN, might have ramifications related to your problem. For what it's worth, I disable GTSAM_BUILD_METIS_EXECUTABLES and enable GTSAM_USE_SYSTEM_EIGEN.

At the top-level, you can disable any metis shenanigans by disabling GTSAM_SUPPORT_NESTED_DISSECTION (it will be enabled by default). I'm pretty sure metis is only used as an alternative ordering strategy, and that colamd is the default, but I am not close at all to that discussion.

So, if rtabmap needs metis, but GTSAM does not, this might be an effective way to sidestep the issue. If rtabmap and GTSAM are communicating metis across a library boundary ... good luck. :)

[parkerlreed]

Strangely both GTSAM_SUPPORT_NESTED_DISSECTION and GTSAM_BUILD_METIS_EXECUTABLES are already off.

I'll see what I can figure out.

[varunagrawal]

@parkerlreed any luck? You definitely want to set GTSAM_SUPPORT_NESTED_DISSECTION=OFF as this flag is responsible for including metis as a library (as @mikesheffler already pointed out).

Sometimes cmake does stupid things and I need to blow up my build directory to actually see the effect of the variable change. Maybe that might help you?

[parkerlreed]

I haven't been able to get back to that in a bit. At the time I did make sure to start fresh and both of those variables were already unset.

I'll see if I can poke at this again a little later today.

[varunagrawal]

@parkerlreed any updates? We are looking to close pending issues. :)

[acxz]

@varunagrawal From what I understand this should have be resolved with #332

[dellaert]

@parkerlreed probably resolved by PR #332, please check and feel free to re-open if not.