Need reviewers: more predictable binaries

[Kelly O'Hair]

I'll fix that.

-kto

On Sep 6, 2012, at 8:28 AM, Erik Joelsson wrote:

> I would like to have sorts added to Demo.gmk too. I just hit a case where it caused a difference for me between old build and build-infra.
> 
> /Erik
> 
> On 2012-09-06 06:08, Kelly O'Hair wrote:
>> 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