This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
- From: Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>
- To: ak at suse dot de (Andi Kleen)
- Cc: dan at debian dot org (Daniel Jacobowitz), weigand at i1 dot informatik dot uni-erlangen dot de, gcc at gcc dot gnu dot org, linux-kernel at vger dot kernel dot org, schwidefsky at de dot ibm dot com
- Date: Thu, 1 Apr 2004 23:01:39 +0200 (CEST)
- Subject: Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
>
> On Thu, 1 Apr 2004 15:39:23 -0500
> Daniel Jacobowitz <dan@debian.org> wrote:
> > >
> >
> > (I haven't tested anything but...) why should this fix it? Ulrich's
> > problem happens when the .o file is flushed from the cache, and then
> > stat'd; it now appears to be older than the .c file. With a change to
> > round up instead, if the .c file is flushed from the cache before the
> > .o, the .c will still suddenly appear to be newer than the .o.
>
> That is what he wants I think. It's logically just like taking a bit longer.
Not really. I have two files generated in sequence:
.c at 08:12:23.1
.o at 08:12:23.2
As long as the .o stays more recent than the .c, everything is fine.
With the current code, this breaks if the .o file is flushed and
re-read, while the .c file stays in cache:
.c at 08:12:23.1
.o at 08:12:23.0 (oops, suddenly in need of rebuild)
With your suggested change, it will break if the .c file is flushed
while the .o file stays in cache (as Daniel pointed out):
.c at 08:12:24.0
.o at 08:12:23.1 (oops, suddenly in need of rebuild)
Both lead to the same type of problem.
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de