On Monday 02 June 2008, Daniel Jacobowitz wrote: > On Mon, Jun 02, 2008 at 01:50:13PM -0600, Bob Proulx wrote: > > Jim Meyering wrote: > > > Mike Frysinger wrote: > > > > for example, if you're running a recent version of glibc (say 2.7) > > > > compiled against recent kernel headers (say 2.6.25) but execute on > > > > an older kernel (say 2.6.18), then the resulting touch binary will > > > > attempt to use utimensat() which fails with ENOSYS. > > > > Most common systems only support backward compatibility. I have not > > heard of a system which supported forward compatibility. > > > > In other words, compiling on a platform usually results in an > > executable that only runs on that version or later of components of > > the system and not usually older versions. That has always been true > > of unix-like systems. Sometimes it happens to work anyway simply by > > the happy chance that nothing in the call graph changed. But it isn't > > generally possible when new interfaces are added to the system. > > FYI, this is not how glibc handles kernel headers, and that's worked > fine for many years. You compile against the newest version you would > like to take advantage of, and specify the oldest version to be > supported separately.
exactly. the default kernel target for Gentoo's glibc atm is 2.6.9, but we almost always build against the latest kernel headers possible. > Mike, I thought the *at wrappers fell back to emulation if the > syscalls were missing. Is that impossible for utimensat? i'm looking at sysdeps/unix/sysv/linux/utimensat.c and does not appear to have any fallback emulation support. i'm not about to try suggesting adding such fallback code to glibc due to drepper, but i think it's a good idea for all of the *at functions. also after reading it, i dont think gnu/stubs.h would help in this particular case. gnulib would need a runtime test to detect that utimensat() is actually not available. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
