> We experienced a problem when makepp was combined with > using distcc on Linux machines. In this case, for larger > object files (typically larger than 100 kB), the time stamp > as stored by makepp could be a few seconds less than > the actual time stamp of the generated object file > (typically the difference was in the region of 1-5 seconds). > > This then generates a rebuild of the object file the next > time the program was built, because makepp checks this > time stamp, and concludes that the object file must have > been modified since its mtime does not match the mtime > stored as a signature by makepp.
OK, so makepp does not store the correct timestamp. How exactly is it distcc's fault? At any rate, the idea behind "make" is to compare the source file and the object file timestamps to decide whether or not the object is up-to-date. I don't see what makepp is expecting from comparing the object file current timestamp with what it stored previously. Sounds like a design silliness, or (most probably) I'm missing something. Care to explain to me? > The problem was immediately solved when disabling the memory > mapped file IO mechanism employed by distcc, by setting > environment variable DISTCC_MMAP to 0: > > export DISTCC_MMAP=0 I admit I don't understand how using mmap can change anything, and I have not been looking into distcc's code yet. I guess that it's just about using mmap()/munmap() and memory operations to write output files instead of read()/write()/close()? Why would it influence the timestamp? I'm curious, and would appreciate if someone could explain. Thanks, -- Jean Delvare http://khali.linux-fr.org/ __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
