[PATCH, v3] Potential solution to librt issue.

Paolo Bonzini bonzini@gnu.org
Thu Jul 24 13:12:00 GMT 2008


> Is that libpthread thing confirmed?

Yes:

$ echo 'int main() {}' > f.c
$ gcc f.c -lrt
$ ldd a.out
         linux-gate.so.1 =>  (0xffffe000)
         librt.so.1 => /lib/librt.so.1 (0xb7f4a000)
         libc.so.6 => /lib/libc.so.6 (0xb7e0c000)
         libpthread.so.0 => /lib/libpthread.so.0 (0xb7df3000)
         /lib/ld-linux.so.2 (0xb7f64000)

I'm not saying it is a "no-no" to use clock_gettime -- but I guess 
you'll agree it is a "no-no" to break performance of single-threaded 
programs because of it, and it is lucky that Dan brought up the point so 
soon.

Possibilities include:

1) implementing clock_gettime on Linux using the system call interface. 
  I guess that the clock_gettime syscall itself does not need pthreads.

2) do some trick with specs.  For example, -Wl,--as-needed -lrt does not 
bring in pthreads unless necessary:

$ gcc f.c -Wl,--as-needed -lrt
$ ldd a.out
         linux-gate.so.1 =>  (0xffffe000)
         libc.so.6 => /lib/libc.so.6 (0xb7da9000)
         /lib/ld-linux.so.2 (0xb7ef8000)

Is <chrono> a template?  If yes, i.e. if there is no code in 
libstdc++.so that needs clock_gettime, you could add the 
"-Wl,--as-needed -lrt -Wl,--no-as-needed" flags to the specs for C++ on 
Linux.

Neither solution is particularly appealing to me. :-(

In the meanwhile, can anyone check the dependencies of -lrt on other 
systems?

Paolo



More information about the Libstdc++ mailing list