<AWT Dev> Fwd: Need reviewers: more predictable binaries

[Kelly O'Hair]

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.ohair at oracle.com>
> Subject: Need reviewers: more predictable binaries
> Date: September 5, 2012 9:08:53 PM PDT
> To: "build-dev at openjdk.java.net build-dev" <build-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120906/b83ba7f4/attachment.html