This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, v3] Potential solution to librt issue.


Paolo Bonzini wrote:
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. :-(

Would declaring a weakref for clock_gettime in libstdc++ work?


Martin


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


Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]