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: Daniel Jacobowitz <dan at debian dot org>
- To: Andi Kleen <ak at suse dot de>
- Cc: Ulrich Weigand <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 15:39:23 -0500
- Subject: Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
- References: <200404011928.VAA23657@faui1d.informatik.uni-erlangen.de> <20040401220957.5f4f9ad2.ak@suse.de>
On Thu, Apr 01, 2004 at 10:09:57PM +0200, Andi Kleen wrote:
> On Thu, 1 Apr 2004 21:28:20 +0200 (CEST)
> Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> wrote:
>
> > However, I'd say that this should probably be fixed in the kernel,
> > e.g. by not reporting high-precision time stamps in the first
> > place if the file system cannot store them ...
>
> Interesting. We discussed the case as a theoretical possibility when
> the patch was merged, but it seemed to unlikely to make it worth
> complicating the first version.
>
> The solution from back then I actually liked best was to just round
> up to the next second instead of rounding down when going from 1s
> resolution to ns.
>
> -Andi
>
> e.g. like this for ext3 (untested). Does that fix your problem?
(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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer