> > > I'm not arguing the rest of your points, but I'm curious about > > > this one. IIRC, the last thing a full bootstrap of GCC does, > > > after building stage one binaries with the native compiler, > > > > Hum, It *used* to do this, can't seem to get it to do it today though > > <oh well> > > > > IIRC it only applied to debug information, it included timestamps or > > some such. > > There is a small header at the beginning of an object file which is > different each time, because it contains a time stamp. > > This is why 'make compare' removes the first 16 bytes of the object > files before comparing. > > for file in *$(objext); do \ > tail +16c ./$$file > tmp-foo1; \ > tail +16c stage$$stage/$$file > tmp-foo2 \ > && (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $$file differs > >> .bad_compare) || true; \ > done
Yes, I've seen that stuff fly (or crawl) past while building gcc, but I don't understand in what circumstances it's required. I can't get gcc to include timestamps when I try it. I think the main spurious diff culprit in debs is gzip (and tar z). It occurred to me that perhaps debs should be built with a hacked/wrapped gzip to avoid this problem. I don't know how autobuilders, etc, work, but I can imagine there may be circumstances where it would be useful to be able to tell immediately that a package was not changed when it was rebuilt after installing a new version of some header file (or whatever) that might, potentially, have caused the package to change. Or is this all properly handled by some different mechanism that I can read about somewhere? Edmund