Mike Frysinger <[EMAIL PROTECTED]> wrote: > a recent gnulib commit (faeb3e6b21...) causes trouble for some packages (such > as touch in coreutils) on certain combinations of software. 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. > > i'm not sure which route is best for gnulib: should it try each version at > runtime and slowly fall back, or should it review the gnu/stubs.h header > provided by glibc so that it knows ahead of time that the utimensat() symbol, > while available in the C library, is not actually usable.
Hi Mike, coreutils/gnulib have always run certain configure-time tests to determine kernel/libc characteristics so that doing that is not necessary at run-time. Often it would be prohibitively expensive (or essentially impossible) to perform such tests at run time. This is especially important for a minimalist tool like touch, but even "larger" tools like cp and ls can perform only very limited (and lightweight) system-attribute-detection at run time -- to do otherwise would induce unacceptable overhead. I'm afraid the best advice I can give you is to run the tools on the same (or newer) version of the system on which you configured the package. Jim
