Just FYI... these build changes do touch sources in various teams, please let me know if you have issues with these changes.
-kto Begin forwarded message: > From: "Kelly O'Hair" <kelly.oh...@oracle.com> > Subject: Need reviewers: more predictable binaries > Date: September 5, 2012 9:08:53 PM PDT > To: "build-...@openjdk.java.net build-dev" <build-...@openjdk.java.net> > > > Need a reviewer for this change. > > http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ > > It does change source, but it's effectively a build change. > > The goal here is to try and create more predictable binary files and remove > the possibility that > a full source path (via __FILE__) gets baked into the shared libraries or > executables shipped. > > So two changes: > * sort the .o files during links so they are always provided to the linker > in the same order. > * replace use of __FILE__ to the macro THIS_FILE with just the basename of > the source file being compiled > > The __FILE__ issue is that it has an implementation defined string literal > value, depending on the compiler > and the filename supplied on the compile line. By changing to the new > THIS_FILE macro, the object files > will always have a consistent string literal in them, making it easier to > compare binaries between builds. > Something we have never been able to do in the past. Granted it's just the > basename for the file, but should be enough. > The tricky part is that __FILE__ only gets evaluated when it is used. In > normal C code, it will appear in > macros but it only will get evaluated in the source file being compiled. It > is rare that macros using > __FILE__ will get expanded in include files and I detected this not > happening in the jdk source at all. > > -kto
