[OpenJDK 2D-Dev] Fwd: Need reviewers: more predictable binaries
scott.kovatch at oracle.com
Thu Sep 6 18:35:35 UTC 2012
I feel like I should be able to find the answer to this, but does Objective-C use CPPFLAGS? I can't tell if these changes would apply to .m or .mm files. It certainly appears to be the intent of the change, since a number of .m files in the AWT were changed to use THIS_FILE.
-- Scott K.
On Sep 6, 2012, at 9:30 AM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
> Just FYI...
> these build changes do touch sources in various teams, please let me know if you have issues with these changes.
> 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.
>> 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.
More information about the core-libs-dev