2

I have the following linking command (sorry for it's length, but I tried to leave it as original as possible, except for shortening some paths):

CC
CMakeFiles/main.dir/main.cpp.o -o main -L/me/libs/cgal/lib -L/me/libs/tbb/tbb-2017_U7/build/linux_intel64_gcc_cc5.3.0_libc2.19_kernel3.12.61_release -rdynamic -lmpfr -lgmp /me/libs/cgal/lib/libCGAL_ImageIO.a /me/libs/cgal/lib/libCGAL.a -lboost_thread -lboost_system -lz /me/libs/cgal/lib/libCGAL_ImageIO.a /me/libs/cgal/lib/libCGAL.a -lboost_thread -lboost_system -lz -ltbb -ltbbmalloc -Wl,-rpath,/me/libs/cgal/lib:/me/libs/tbb/tbb-2017_U7/build/linux_intel64_gcc_cc5.3.0_libc2.19_kernel3.12.61_release

It will tell me:

/usr/bin/ld: cannot find -ltbb

/usr/bin/ld: cannot find -ltbbmalloc

Most probably relevant for the problem is that I have -L/me/libs/tbb/tbb-2017_U7/build/linux_intel64_gcc_cc5.3.0_libc2.19_kernel3.12.61_release and -ltbb - ltbbmalloc. In that -L directory, there is a libtbb.so and a libtbbmalloc.so.

But why are those libraries not found by the linker, even though they clearly exist in a directory given by -L?

EDIT1: I was asked to check with file command. I get the following answers:

  • The *.o file is ELF 64-bit LSB relocatable, x86-64, version 1 (GNU/Linux), not stripped
  • The libtbb.so.2 is ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

Seems not exactly the same, but I have no idea whether it's compatible. Basically, I compiled it with the same compiler. But I'm not sure whether the build system of TBB might have sneaked in some other options.

EDIT2: I was also asked to use strace. A short excerpt shows:

open("/me/libs/tbb/tbb-2017_U7/build/linux_intel64_CC_cc5.3.0_libc2.19_kernel3.12.61_release/libtbb.so", O_RDONLY) = 12
[pid 102330] open("/me/libs/tbb/tbb-2017_U7/build/linux_intel64_CC_cc5.3.0_libc2.19_kernel3.12.61_release/libtbb.so", O_RDONLY) = 11
[pid 102330] open("libtbb.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 102330] open("/me/libs/cgal/lib/libtbb.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 102330] open("/me/libs/tbb/tbb-2017_U7/build/linux_intel64_CC_cc5.3.0_libc2.19_kernel3.12.61_release/libtbb.so.2", O_RDONLY) = 11

It seems that it checks some files and then finally finds the one it is looking for.

Community
  • 1
  • 1
Michael
  • 7,407
  • 8
  • 41
  • 84
  • 1
    Maybe they are for a wrong architecture. Check with `file` command. – n. m. could be an AI Aug 20 '17 at 13:42
  • 1
    Try passing --verbose to the linker and see which files it tries to open. If that fails, try `strace -e open -f your-compilation-command`. – n. m. could be an AI Aug 20 '17 at 14:19
  • I still wonder whether the ELF formats might be incompatible...? – Michael Aug 20 '17 at 14:35
  • It looks like the linker opens and discards the files. What does -Wl,--verbose say? It should give a reason why a library file wasn't used. – n. m. could be an AI Aug 20 '17 at 15:05
  • Unfortunately, it does not give any more information. No matter whether I try verbose directly with calling `ld` or with `-Wl`. – Michael Aug 20 '17 at 15:13
  • What does it say? I should say "attempt to open ... succeeded/failed" and then perhaps "skipping incompatible ..." – n. m. could be an AI Aug 20 '17 at 15:28
  • Unfortunately, it does not give any more output. It's still just "/usr/bin/ld: cannot find -ltbb /usr/bin/ld: cannot find -ltbbmalloc". – Michael Aug 20 '17 at 15:30
  • 1
    Something's wrong here. If the linker tries to open a file, it should report it in the verbose mode. If it reports nothing, it doesn't attempt to open it. But strace says it is opened. Perhaps it is opened but not by ld? You can look at who opens what with strace -f -e open,execve. Also look at the arguments CC passes to ld. – n. m. could be an AI Aug 20 '17 at 15:53
  • How can I see what arguments CC passes to ld? (I know the -Wl option, but I'd like to see how ld is actually called.) – Michael Aug 20 '17 at 16:12
  • 1
    Just -v at the to level. strace will also show them. – n. m. could be an AI Aug 20 '17 at 16:38
  • @n.m.: It turns out that the linker (`GNU ld (GNU Binutils; SUSE Linux Enterprise 12) 2.25.0`) only looks for libraries ending with *.a, while I have `*.so`. I'm not sure whether I need to build `*.a` from the library or teach the linker to use `*.so`. – Michael Aug 20 '17 at 19:03
  • Ok, finally I found the true problem: Intel TBB discourages using static libraries and therefore only builds shared ones, while my Cray system requires can not handle shared libraries and requires static ones. Seems that they provide a work-around. Thanks a lot for your help :-) – Michael Aug 20 '17 at 19:27

0 Answers0