Messages in this thread | | | Date | Thu, 1 Apr 2004 19:13:05 -0500 | From | Daniel Jacobowitz <> | Subject | Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build |
| |
On Thu, Apr 01, 2004 at 03:58:45PM -0800, Joe Buck wrote: > On Fri, Apr 02, 2004 at 12:48:55AM +0200, Ulrich Weigand wrote: > > Joe Buck wrote: > > > > > Case 2: make falsely thinks that the .c is younger than the .o. It > > > recompiles the .c file, even though it didn't have to. Harmless. > > > > *Not* harmless, in fact this is exactly what breaks my bootstrap. > > > > Think about what happens when cc1 is 'harmlessly' rebuilt just > > while in a parallel make that very same cc1 binary is used to > > run a compile ... > > Well, then, you have a problem: how to handle ties? Consider a system > with no extra precision, and one-second time resolution. You see an .o > file and a .c file that are the same age. Rebuild or not? If we don't > and are wrong, the .o file is bad. If we do and are wrong, the target > will be modified while some process is trying to use it. Somehow we > have to figure out how to do the makefile so that neither problem can > occur.
Don't rebuild. If you have makefiles set up that the .o and _then_ the .c can be rebuilt by parallel threads, you've got lots more wrong already! And it's a reasonable assumption that the entire build, test, notice something is wrong, fix, rebuild cycle takes longer than the granularity of your timestamps.
> In your particular case, for example, if the command to rebuild cc1 builds > the new version in a different place, then does an mv, the rebuild *will* > be harmless.
No, that's not right - read what Ulrich wrote originally about the wrong options being in scope (exported by make) at this point -> bootstrap miscompares.
-- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |