0

I'd like to use CMake, GTest, and Intel's TBB for a project on linux, and so far I've been able to build without complaint, but the dynamic linking required by TBB has been a bit of an issue for only one of their libraries.

I'm using their CMake functions invoked like so:

set(TBB_ROOT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/tbb)
set(TBB_BUILD_DIR "tbb_build_dir=${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}")
set(TBB_BUILD_PREFIX "tbb_build_prefix=tbb")

include(${TBB_ROOT_DIR}/cmake/TBBBuild.cmake)

tbb_build(TBB_ROOT ${TBB_ROOT_DIR} 
          MAKE_ARGS 
              ${TBB_BUILD_DIR} 
              ${TBB_BUILD_PREFIX} 
          CONFIG_DIR 
          TBB_DIR)

find_package(TBB REQUIRED)

When running, I get the error:

error while loading shared libraries: libtbbmalloc_debug.so.2: cannot open shared object file: No such file or directory

After Running ldd <whatever_test_executable> I get the following output

linux-vdso.so.1 =>  (0x00007fff741b9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd99a6fd000)
libtbb_debug.so.2 => /home/mrbzapp/test_proj/build/Builds/lib/tbb_debug/libtbb_debug.so.2 (0x00007fd99a489000)
libtbbmalloc_proxy_debug.so.2 => /home/mrbzapp/test_proj/build/Builds/lib/tbb_debug/libtbbmalloc_proxy_debug.so.2 (0x00007fd99a285000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd99a081000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fd999dd4000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fd999a99000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fd999887000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fd99967f000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd9992f7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd998fee000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd998dd7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd998a0e000)
/lib64/ld-linux-x86-64.so.2 (0x000055a935c16000)
libtbbmalloc_debug.so.2 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd9987f2000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007fd9985c0000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fd99839e000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fd998198000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fd997f92000)

During build I can see that CMake (and TBB's TBBBuild function) is adding /home/mrbzapp/test_proj/build/Builds/lib/tbb_debug/ to the rpath, and for most of the linked tbb libs they are using this path, but libtbbmalloc_debug.so.2 is being left out in the cold and it's bringing the whole thing down with it.

What I find completely baffling is that libtbbmalloc_debug.so.2 does exist, and exists alongside the other TBB libraries that are using the rpath set by TBB's functions.

What could I possibly be doing wrong, and what might I have to do in order to make sure all of these libraries are correctly linked at runtime and not just a handful?

MrBZapp
  • 109
  • 7

2 Answers2

1

MrBZapp.

I was able to reproduce this problem, thank you for reporting it. The problem is that libtbbmalloc_proxy_debug.so.2 can't find libtbbmalloc_debug.so.2 As a workaround I can propose you to "source /home/mrbzapp/test_proj/build/Builds/lib/tbb_debug/tbbvars.sh intel64" in your environment and after that execute your application.

Alexey Moskalev
  • 26
  • 1
0

Found a way to make things work, and extra details were probably in order.

I was using specifying the links by writing target_link_libraries(<target> ${TBB_IMPORTED_TARGETS}) when I ought to have been using target_link_libraries(<target> TBB::tbb)

I'm not positive this is the "correct" way to do things, but it is seems to be a way that is working.

MrBZapp
  • 109
  • 7
  • This was not the correct way to do things. The application was capable of executing, but TBB was not able to manage its memory resulting in all manner of weird crashes. Thanks to Alexey Moskalev for the workaround! – MrBZapp Sep 30 '17 at 17:43