bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: touch and utimens troubles on new/old software combinations


From: Mike Frysinger
Subject: Re: touch and utimens troubles on new/old software combinations
Date: Mon, 2 Jun 2008 16:04:18 -0400
User-agent: KMail/1.9.7

On Monday 02 June 2008, Jim Meyering wrote:
> Mike Frysinger <address@hidden> 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.
>
> 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.

the tools are being configured, built, and run on the same system.  that is 
why i suggested incorporating gnu/stubs.h into the gnulib tests as a simple 
configure compile test.  or a configure run test to see if the function 
merely returns ENOSYS (and is therefore a stub) ... this just happens to not 
be as nice as the stubs.h test for end users.

what we have today is that you cannot safely use the utimens gnulib module on 
a newer glibc but older kernel.  the glibc contains all the relevant symbols, 
but they all return ENOSYS.  i dont think telling end users that they're 
expected to construct an obscure list of symbols (which there is no 
documentation for), reconstruct them into the appropriate variable form 
(which there is no documentation for), and put them into the env/run so as to 
force the configure tests for every single package that happens to import the 
utimens gnulib code is realistic.  *i* can do this sort of thing just fine, 
but i'm not accounting for myself here.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]