PR/15448: add a compiler timestamp to PCH files

Geoffrey Keating geoffk@geoffk.org
Thu Feb 17 09:51:00 GMT 2005


Paolo Bonzini <paolo.bonzini@lu.unisi.ch> writes:

> The executable path can be used on Linux to find the compiler
> timestamp (see the attached patch).  A similar test is used in
> libjava, but I enhanced it by supporting the cache variable even in
> the cross-compilation case (Canadian in gcc's case), so that the test
> can be overridden.
> 
> Unlike Autoconf's AC_CHECK_FILES, an absolute path is expected and the
> leading / is accounted for when creating the name of the #define (so
> we have HAVE_PROC_SELF_EXE while Autoconf would yield
> HAVE__PROC_SELF_EXE).
> 
> > To fix the problem you describe, the PCH building rules in libstdc++
> > should just always rebuild them.  If they want to get crafty, they
> > can check the timestamp on the compiler (cc1plus), and ensure that
> > the PCH is rebuilt if the compiler is newer.
> 
> That's just a workaround (maybe a necessary one in GCC, where
> libstdc++-v3 also acts as a PCH testsuite).  But it cannot be used
> outside GCC, even though the bug is present there for people who build
> their own GCC and are not developers.  Non-bootstrapped, bootstrapped
> and profiledbootstrapped installations, for example, have the same
> version string but their PCH's are incompatible.
> 
> The attached patch was bootstrapped and regtested (C/C++ only) on
> i686-pc-linux-gnu, and I checked on powerpc-darwin that
> HAVE_PROC_SELF_EXE is not misdetected.  Ok for mainline?

Using the size is fine, but using the modification time is not a good
idea; modification times are fragile, they can be changed by
installers, prelinking, system restores, etc.



More information about the Gcc-patches mailing list