RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building on windows

Erik Joelsson erik.joelsson at oracle.com
Mon Jan 26 09:47:06 UTC 2015

Adding core-libs-dev looking for a reviewer for the unpack200 changes.

In the old build, unpack200.exe was linked with cl.exe instead of 
link.exe like all other executables and libraries. Since the formatting 
of options is completely different, the same linker flags were not used. 
In this change, I'm removing this special treatment of unpack200.exe so 
that it is linked just like all other executables.


On 2015-01-22 15:40, Erik Joelsson wrote:
> Hello,
> Please review this patch, which makes it possible to take a compile 
> command line from the make debug log on Windows, and rerun it in a 
> normal cygwin environment, without the need for running vsvars*.bat 
> first.
> When building native code on windows, using Visual Studio, configure 
> extracts the build environment from the setup .bat file provided by VS 
> and sets 3 variables in spec.gmk: PATH, INCLUDE and LIB. These 3 
> variables are also exported into the environment in spec.gmk, so that 
> every tool run by the build will see them. While this is convenient, 
> it makes the command lines used by the build unusable outside of the 
> build, unless you also export these variables with the correct values.
> I have removed the need for INCLUDE and LIB to be exported, by 
> converting their contents into compiler and linker flags. These flags 
> conceptually fit well in the recent SYSROOT_CFLAGS and SYSROOT_LDFLAGS 
> variables.
> The PATH variable would be nice to not have to set, and while not 
> setting it seems to work most of the time, I suspect that there are 
> cases when it won't work. More specifically, in certain environments, 
> some dll needed by the compiler program might not be on the path 
> without it. So I left it being set for now.
> The new LDFLAGS requires unpack200.exe to stop being linked 
> differently to all other executables. There is no reason for this 
> discrepancy that I can find, it just seems like someone did a bit of a 
> quick hack getting it to build long ago in the old build, and we 
> wanted to keep it equivalent in build-infra.
> The hotspot build still requires the variables to be exported, so they 
> are still being defined in hotspot-spec.gmk.
> While working on this, I stumbled on a problem when running "make 
> reconfigure". The PATH variable value, since exported in make, would 
> get longer and longer for each time you run reconfigure. I fixed this 
> by saving the original path and resetting it before running configure 
> from make.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071329
> Webrevs:
> http://cr.openjdk.java.net/~erikj/8071329/webrev.root.01/
> http://cr.openjdk.java.net/~erikj/8071329/webrev.jdk.01/
> /Erik

More information about the core-libs-dev mailing list