Subject: toolchain/17703: [dM] source tree timestamps matter
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 07/24/2002 14:52:25
>Synopsis: [dM] source tree timestamps matter
>Arrival-Date: Wed Jul 24 06:03:00 PDT 2002
>Originator: der Mouse
>Release: NetBSD 1.6D
System: NetBSD mouse-ultra.pasta.cs.uit.no 1.6D NetBSD 1.6D (GENERIC) #0: Mon Jul 22 11:31:50 CEST 2002 firstname.lastname@example.org:/usr/src/sys/arch/sparc64/compile/GENERIC sparc64
Also reported on i386 (see PR 17668).
In at least two and possibly more places, a build fails if
certain files' timestamps are out of order with respect to one
another. Specifically: (a) in /usr/src/gnu/dist/toolchain/gcc,
if c-parse.gperf is newer than c-gperf.h, a build attempt tries
to run gperf; (b) in /usr/src/gnu/dist/toolchain/libstdc++, if
valarray.cc is newer than valarray, a build attempt tries to
compile the former onto the latter (which attempt failed for
me, fortunately, because it uses some include files that
haven't yet been installed at that point - if the include files
had been installed, I conjecture it would have installed an
executable under $DESTDIR/usr/include/).
Given that source trees' timestamps don't conceptually matter
(only the contents), and that we don't and can't control all
the tools that copy them around, ISTM that the build procedures
need to be fixed such that they work regardless of the mtimes
on the source tree (though I would find it acceptable to
require that they all be in the past).
try to do a build
try to do a build
Probably other possibilities too; I'm sure I haven't found them
Unknown. I will be happy to write a small program to randomize
the timestamps in a directory hierarchy, to help find further
such bugs, if anyone cares.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
sparc64 snapshot 20020526-1.6A; see also PR 17668.