-
Bug
-
Resolution: Fixed
-
P4
-
9
-
b51
-
windows
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082058 | emb-9 | Erik Joelsson | P4 | Resolved | Fixed | b51 |
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 would like to remove the need for INCLUDE and LIB to be exported, by converting their contents into compiler and linker flags. These flags would conceptually fit well in the new 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 will leave it being set for now.
The new LDFLAGS will require unpack200.exe to stop being linked differently to all other executables. There is no reason for this 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 will still require the variables to be exported, so they will still be defined in hotspot-spec.gmk.
I would like to remove the need for INCLUDE and LIB to be exported, by converting their contents into compiler and linker flags. These flags would conceptually fit well in the new 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 will leave it being set for now.
The new LDFLAGS will require unpack200.exe to stop being linked differently to all other executables. There is no reason for this 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 will still require the variables to be exported, so they will still be defined in hotspot-spec.gmk.
- backported by
-
JDK-8082058 Stop exporting INCLUDE and LIB when building on windows
-
- Resolved
-
- relates to
-
JDK-8016523 Clean up how unpack200.exe is compiled and linked on windows.
-
- Resolved
-