[OpenJDK 2D-Dev] Fwd: Need reviewers: more predictable binaries (original) (raw)

Mike Swingler swingler at apple.com
Thu Sep 6 18:42:29 UTC 2012

My strong suspicion is that the JDK Makefiles only use CFLAGS, not CPPFLAGS for .m files. CPPFLAGS should be used for .mm files (but those should be really rare).

Regards, Mike Swingler Apple Inc.

On Sep 6, 2012, at 11:35 AM, Scott Kovatch <scott.kovatch at oracle.com> wrote:

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 THISFILE.

-- 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. -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 THISFILE 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 THISFILE 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

More information about the core-libs-dev mailing list