Doesn't link to clock_gettime

[renorm]

After upgrading GCC from Ubuntu repository, TBB projects refuse to link.

$ g++ fibonacci.cpp -ltbb
/usr/bin/ld: /tmp/cctNLcQ2.o: undefined reference to symbol 'clock_gettime@@GLIBC_2.2.5'
/usr/bin/ld: note: 'clock_gettime@@GLIBC_2.2.5' is defined in DSO //lib64/librt.so.1 so try adding it to the linker command line
//lib64/librt.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

Adding -lrt to the comand line as the error messages suggets fixes the problem. I am not sure what is going. Could it be because of borken GCC installation?

[Alexey-Kukanov]

TBB binaries depend on certain versions of GCC (more exactly, on shared libraries shipped with these versions). In case you updated GCC from 3.x to 4.x, you likely need to link with a different TBB library than before. But if the update is within GCC 4.x (for example from 4.2 to 4.5), it's not the case.

Another guess is that the previous version of GCC was somehow configured to automatically link with librt.

[Vladimir_P_1234567890]

It looks this happens with default gcc 4.5.x installed on the latest fedora and ubuntu

we will change makefiles to support this.

--Vladimir

[Alexander_Herz]

Hi,

I'm having the same problem on mint 14 and gcc4.7 with tbb4.1. How is this suposed to work? Should tbb automatically link the correct lib or do I need to do it manually when linking tbb into my executable? It would be nice if tbb did this since librt is non-standard and unavailable on e.g. osx so I would need to build/change the configure stuff for my app depending on some dependency inside tbb...

Thx, Alex

[Vladimir_P_1234567890]

Hello Alex

There is a dependency from librt.so.1 in the binaries, so the librt.so.1 library should be picked up by ld. what tbb version do you use (build date) that does not work in this way?
Regarding OSX-do you try to  use linux binaries on mac? why do you need to link with librt there? our libraries do not link with this library on mac.

thanks
--Vladimir

[Alexander_Herz]

Hi Vladimir,

on OSX librt is not requested by tbb (or anything) but when manually linking to librt on linux portability is destroyed.

I'm building tbb from source but I renamed the root directory, how can I figure out my exact version?

I have made 2 minor changes to the sources:

 - I redirect calls to pthreads through the boehm garbage collector by including an alternative pthread.h

 - I link boehm's libs

Apparently, the ref to librt is missing:

aherz@aherz-Precision-T1500:~/funky/funkyimp/lib$ ldd libtbb.so.2
    linux-vdso.so.1 =>  (0x00007fff38fff000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe96ed49000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe96eb2b000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe96e827000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe96e611000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe96e251000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe96f1a0000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe96df55000)
aherz@aherz-Precision-T1500:~/funky/funkyimp/lib$ ldd libtbbmalloc.so.2
    linux-vdso.so.1 =>  (0x00007fff9edff000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9bb2a0e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9bb27f0000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9bb2431000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f9bb2e63000)

[Vladimir_P_1234567890]

Alexander Herz wrote:

I'm building tbb from source but I renamed the root directory, how can I figure out my exact version?

what is "INTERFACE VERSION"?

[bash]
# strings libtbb.so.2 | grep INTERFACE VERSION
[/bash]

And did you use tbb's build system from that package to build the library? Other words is -lrt still in options you passed to the linker when you were building the library?

--Vladimir

[Alexander_Herz]

I'm building using tbb's build system (just calling make in the root dir).

I added the following in build/Makefile.tbb to use the garbage collector:

LIB_LINK_FLAGS  += -L$(tbb_root)/../boehm/bdwgc/.libs -lgccpp -lgc

CPLUS_FLAGS += -I$(tbb_root)/../pthread_redirect #-L$(tbb_root)/../boehm/bdwgc/.libs -lgccpp -lgc

The rest is unchanged. It's version 6.1.

Alex

[Alexander_Herz]

make -n gives

g++ -fPIC -o libtbb.so.2 concurrent_hash_map.o concurrent_queue.o concurrent_vector.o dynamic_link.o itt_notify.o cache_aligned_allocator.o pipeline.o queuing_mutex.o queuing_rw_mutex.o reader_writer_lock.o spin_rw_mutex.o spin_mutex.o critical_section.o task.o tbb_misc.o tbb_misc_ex.o mutex.o recursive_mutex.o condition_variable.o tbb_thread.o concurrent_monitor.o semaphore.o private_server.o rml_tbb.o task_group_context.o governor.o market.o arena.o scheduler.o observer_proxy.o tbb_statistics.o tbb_main.o concurrent_vector_v2.o concurrent_queue_v2.o spin_rw_mutex_v2.o task_v2.o   -ldl -lpthread -lrt -shared -Wl,-soname=libtbb.so.2 -m64 -L../../../boehm/bdwgc/.libs -lgccpp -lgc  -Wl,--version-script,tbb.def

So -lrt is specified but there seems to be no effect.

Alex

[Alexander_Herz]

Hi again,

I had a look at the tbb sources and found the problem. clock_gettime is not used in any cpp file if __linux__ is defined (only in headers), so the linker discards -lrt as no dependencies to that in the object files exist. By adding something like the following in e.g. tbb_thread.cpp the problem is solved (and the dep to librt is added to libtbb.so):

void FORCE_LINK_LIBRT()
{
#if __linux__
tick_count::now();
#endif
}

tbb_thread.cpp uses tick_count::now();, but only if _WIN32||_WIN64 is defined, not for __linux__.

Is this fixed in tbb 4.2?

Regards, Alex

[Vladimir_P_1234567890]

hello Alex,

No, situation is the same in TBB 4.2. On ubuntu-based systems it is needed to use -lrt in case tbb::tick_count is used. We are trying to find out what should be set to linker in order to keep this dependency.

Thanks for the example. We need to find a good place to put such code because a good compiler should remove such standalone function on the optimization step and the issue would revert to previous one.

--Vladimir

[Vladimir_P_1234567890]

Libtool documentation says that default value of link_all_deplibs variable is ‘unknown’, which is a synonym for ‘yes’.

It looks that Debian/Ubuntu has changed default behavior of libtool and has not documented this.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702737 for details.

--Vladimir