Upstream seems to have intentionally done this otherwise. From libev/ev.c:

/* on linux, we can use a (slow) syscall to avoid a dependency on pthread, */
/* which makes programs even slower. might work on other unices, too. */

Your proposed change doesn't actually cause the binaries to be linked against librt either.

The conftests fail with undefined reference because of bad argument order.

This doesn't happen on my installation for various reasons, I should've noticed :) Anyway, that comment in libev doesn't seem to make any sense whatsoever these days.

There are multiple solutions to beat the configure check, with

LIBEV_M4_AVOID_LIBRT=0 LIBS="-lrt" being the most simple.

$ LIBEV_M4_AVOID_LIBRT=0 LIBS='-lrt' ./configure|grep clock
checking for clock_gettime... yes

$ LIBS='-lrt' ./configure|grep clock
checking for clock_gettime... yes

$ ./configure|grep clock
checking for clock_gettime... no
checking for clock_gettime syscall... yes

I doesn't see the usage of LIBEV_M4_AVOID_LIBRT=0 and quickly looking the code:

$ grep LIBEV_M4_AVOID_LIBRT configure
LIBEV_M4_AVOID_LIBRT=1
if test -z "$LIBEV_M4_AVOID_LIBRT" && test -z "$ac_have_clock_syscall"; then
if test -z "$LIBEV_M4_AVOID_LIBRT"; then


$ grep -C 1 LIBEV_M4_AVOID_LIBRT=1 configure

LIBEV_M4_AVOID_LIBRT=1

If VDSO is enabled in glibc, there is no difference between clock_gettime syscall and a classic function call. I doesn't see why each application need to be changed.

You don't understand how the VDSO works. The kernel maps it into userspace and then .. the magic ends. Either userspace makes use of these functions or not - the kernel does not enforce it in any way.

If you use the generic syscall interface you can't use them, plain and simple.

You can't simply shrug off an author comment without explaining why you think it makes no sense. Bring it up with upstream if you believe it's entirely nonsensical "these days".

I don't understand...

When you call clock_gettime function in you c code, you call a glibc wrapper.
This wrapper potentially use a soft interrupt (int 0x80) / sysenter / vsyscall / vdso / custom cpu instruction (modern cpu) to get the answer. The magic is here!

Look inside clock_gettime implementation in glibc[1], you can see the complexity of this "syscall".

You can read [2], where they explain relation between glibc / syscall / sysenter
<quote>
Thus, the C library can use the fastest type of system call by jumping to a fixed address in the vsyscall page.
</quote>

You can also read [3], where relation between vdso, vsyscall and glibc are discuced on lwn.
<quote>
Contemporary applications should not be doing that most of the time, except for one little problem: glibc still uses the vsyscall version of time(). That has been fixed in the glibc repository, but the fix may not find its way out to users for a while; meanwhile, time() calls will be a little slower than they were before.
</quote>

So, i short, using vdso, is glibc stuff not rxvt-unicode one.

[1] http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/clock_gettime.c.
[2] http://www.win.tue.nl/~aeb/linux/lk/lk-4.html
[3] http://lwn.net/Articles/446528/

@seblu: You looked up the wrong function (there are about 5 files named clock_gettime), use outdated information more or less irrelevant to modern distributions and manage to come to the wrong conclusion - congratulations.

@falconindy: Sure I can. Not doing hundreds or even thousands (Think urxvtd and doing actual work.) of unnecessary syscalls per second vs linking against librt is a complete nobrainer.

My point was about complexity of clock_gettime functions, but focus on wrappers. glibc already use interupt less.

Jason, did you understand what i would says about glibc wrappers and use of vdso/vsyscall inside?

I made a small test with test.c (attached). I attached strace -T output and no call to clock_gettime is done.

hum.

$ strace -f -p 3147 -e 'clock_gettime'
Process 3147 attached
clock_gettime(CLOCK_MONOTONIC, {1132905, 521487010}) = 0
clock_gettime(CLOCK_MONOTONIC, {1132905, 521513668}) = 0
clock_gettime(CLOCK_MONOTONIC, {1132910, 513344909}) = 0

Currently urxvt is linked to librt but doesn't use its clock_gettime. Fine.
$ ldd =urxvt|grep librt
librt.so.1 => /lib/librt.so.1 (0x00007f53eb60f000)

configure test if clock_gettime is working without linking with -lrt. So glibc wrapper is not found and rxvt-unicode define his own wrapper around syscall (2).

Jason, as Dave said, it could be interesting to have upstream point of view about their comment around pthread.

Jason you thought to contact upstream?