Mechanism for getting dependent Libraries fails on Linux

[Chris Beall]

When building the pre-compiled Matlab toolbox:

get_target_property(dependentLibraries ${lib} INTERFACE_LINK_LIBRARIES)

works fine on Mac OS to collect dependent Libraries, but fails on Linux. Added temporary work-around in commit d575d7f.

[Frank Dellaert]

I am having issues that when I change something in Rot3.cpp, I have to make install before testRot3 links with the change. If you forget: segfault or no change (as you're really executing the old code). That seems very wrong.

[Chris Beall]

This issue is about something that I ran into when building the statically linked Matlab toolboxes, and it's a slightly different issue. In any case, on Mac please try otool -L testRot3 to check what's being loaded. All is well on Linux:

cbeall3@cbeall3-desktop:~/git/gtsam/build-quaternion/gtsam/geometry/tests$ ldd testRot3
    linux-vdso.so.1 =>  (0x00007fff37dd5000)
    libgtsam.so.3 => /home/cbeall3/git/gtsam/build-quaternion/gtsam/libgtsam.so.3 (0x00007f2ef442b000)
    libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f2ef41fe000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2ef3ef9000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2ef3bf3000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2ef39dd000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ef3616000)
    libboost_serialization.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_serialization.so.1.54.0 (0x00007f2ef33ab000)
    libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f2ef3195000)
    libboost_timer.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_timer.so.1.54.0 (0x00007f2ef2f8f000)
    libtbb.so.2 => /usr/lib/libtbb.so.2 (0x00007f2ef2d5b000)
    libtbbmalloc.so.2 => /usr/lib/libtbbmalloc.so.2 (0x00007f2ef2b23000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2ef498f000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2ef2904000)
    libboost_chrono.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.54.0 (0x00007f2ef26fd000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2ef24f8000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2ef22f0000)

[Frank Dellaert]

Well, that indicates the problem:

pureZero-4:geometry/tests>otool -L testRot3
testRot3:
    /Users/frank/git/gtsam/build3/gtsam/libgtsamRelWithDebInfo.3.dylib (compatibility version 3.0.0, current version 3.1.0)
    /opt/local/lib/libboost_serialization-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_filesystem-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_date_time-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_regex-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_timer-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    libtbb.dylib (compatibility version 0.0.0, current version 0.0.0)
    libtbbmalloc.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
pureZero-4:geometry/tests>mate testRot3.run

The first library is the installed one...

[Chris Beall]

I don't follow. Looks like the library is in your build folder. I would expect your installed copy to end up at /Users/frank/lib/libgtsamRelWithDebInfo.3.dylib. So as long as it's not using that one when you do make check everything should be fine?

[Frank Dellaert]

You are right - I'm blind. But, unless I install, it does not work. Go figure...

[Frank Dellaert]

Assigning to reporter @cbeall3 so someone is on the hook to close or wontfix :-)