Jim Meyering wrote:
> > So, any objections to removing this module?
>
> Why don't we first mark it as obsolete?
> I'll stop using it in coreutils right away, and we can
> remove it altogether after a reasonable grace period.
OK, I've committed the cross-compilation fix and done that:
2009-04-10
Bruno Haible wrote:
> Paolo Bonzini wrote:
>> I'll make it say "guessing yes" and still put "yes" in the variable.
>
> Thanks. Here is what the adaptation in gnulib could look like. But frankly,
> I'll prefer to remove the module altogether: The bug it cures occurred only
> on Sequents; the last ti
Bruno Haible wrote:
> Paolo Bonzini wrote:
>> I'll make it say "guessing yes" and still put "yes" in the variable.
>
> Thanks. Here is what the adaptation in gnulib could look like. But frankly,
> I'll prefer to remove the module altogether: The bug it cures occurred only
> on Sequents; the last t
Paolo Bonzini wrote:
> I'll make it say "guessing yes" and still put "yes" in the variable.
Thanks. Here is what the adaptation in gnulib could look like. But frankly,
I'll prefer to remove the module altogether: The bug it cures occurred only
on Sequents; the last time I heard about this kind of
>>> - ac_cv_func_utime_null=no)])
>>> + ac_cv_func_utime_null=yes)])
>> I'd write this as 'ac_cv_func_utime_null="guessing yes"', to make it obvious.
>
> It would be a tad more backwards-compatible to stick with "yes".
> Consider a configure.ac that does this,
>
> AC_
Eric Blake wrote:
> Paolo Bonzini gnu.org> writes:
>
>> > This macro is obsolescent, as all current systems have a `utime'
>> > that behaves this way. New programs need not use this macro.
>>
>> I think that then _this_ is the cross-compilation default to be fixed.
>>
>> Ok?
>
> Fix the
Paolo Bonzini gnu.org> writes:
> > This macro is obsolescent, as all current systems have a `utime'
> > that behaves this way. New programs need not use this macro.
>
> I think that then _this_ is the cross-compilation default to be fixed.
>
> Ok?
Fix these nits before applying:
>
> This is the main problem: autoconf guessed wrong. The AC_FUNC_UTIME_NULL macro
> is already obsolete for 3 years:
>
> -- Macro: AC_FUNC_UTIME_NULL
> If `utime (FILE, NULL)' sets FILE's timestamp to the present,
> define `HAVE_UTIME_NULL'.
>
> This macro is obsolescent, as all c
Bruno Haible writes:
> I propose to either
> a) Change the cross-compiling default in m4/utime.m4 to
> "ac_cv_func_utime_null=yes", or
> b) Remove the 'utime' module altogether.
Thanks for the analysis. Either solution would be OK, but surely (b)
would be better, as nowadays the module
Pádraig Brady wrote:
> So would this simplification be appropriate, which just handles systems
> where utime("file", &ut); is OK while utime("file", NULL); is not?
Often, when files are exported over NFS, the server and the client have
different clocks. The write() call assigns to the file the cur
Andreas Schwab wrote:
> Pádraig Brady writes:
>
>> So would this simplification be appropriate, which just handles systems
>> where utime("file", &ut); is OK while utime("file", NULL); is not?
>
> Note that utime(,0) requires less privileges than utime(,&ut). For the
> latter you need to be own
Pádraig Brady writes:
> So would this simplification be appropriate, which just handles systems
> where utime("file", &ut); is OK while utime("file", NULL); is not?
Note that utime(,0) requires less privileges than utime(,&ut). For the
latter you need to be owner, whereas the former only requir
Jim Meyering wrote:
> ipif wrote:
>> I'm using coreutils-7.2 on an embedded sparc V8 with linux-2.6.21 and
>> uclibc-0.9.30.
>> The problem is, that in utime.c(73) it is tried to read a char from the file
>> and to write it back. As the fifo is empty touch gets stuck waiting for
>> input.
>> Becaus
13 matches
Mail list logo
