Re: compiling openJdk 11 on windows 7 32bits fail
I used this command: *bash ./configure --enable-debug --with-target-bits=32 --with-toolchain-version=2017 --with-jvm-variants=client --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";* I tried Visual studio 2015 and 2017 (with-toolchain-version). I attached config.log as you asked. Thanks. El sáb., 3 de nov. de 2018 a la(s) 04:43, Magnus Ihse Bursie ( magnus.ihse.bur...@oracle.com) escribió: > Have you tried running > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > > from the same prompt you ran configure to see what happens? It seems to > have located a compiler but fails to run it. > > There is also a second log file, config.log, generated by autoconf. It > will hopefully contain output from the failed run of CL, and the > complete command line it used when it concluded that the C compiler > cannot create executables. > > /Magnus > > On 2018-11-03 02:50, Franco Gastón Pellegrini wrote: > > Hello, > > When I try to compìle OpenJDK 11, I get an error. I tried using visual > > studio 2015 and 2017 with the same error. *Note that compiling OpenJDK 9 > > and 10 work just fine.* > > > > I attached the log, but the error is: > > > > ** > > ** Visual Studio 2017 Developer Command Prompt v15.8.9 > > ** Copyright (c) 2017 Microsoft Corporation > > ** > > [vcvarsall.bat] Environment initialized for: 'x86' > > configure: Setting extracted environment variables > > checking for Visual Studio variables... ok > > configure: Rewriting ipath to > > > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include" > > configure: Rewriting ipath to > > "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um" > > configure: Rewriting ipath to > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt" > > configure: Rewriting ipath to > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared" > > configure: Rewriting ipath to > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um" > > configure: Rewriting ipath to > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt" > > configure: Rewriting ipath to > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt" > > configure: Rewriting libpath to > > > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86" > > configure: Rewriting libpath to > > "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86" > > configure: Rewriting libpath to > > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86" > > configure: Rewriting libpath to > > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86" > > checking for cl... > > > /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl > > configure: Rewriting CC to > > > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl" > > checking resolved symbolic links for CC... no symlink > > configure: Using microsoft C compiler version 19.15.26732.1 [Microsoft > (R) > > C/C++ Optimizing Compiler Version 19.15.26732.1 for x86] > > checking whether the C compiler works... no > > configure: error: in `/home/Franco/Java/jdk11': > > configure: error: C compiler cannot create executables > > See `config.log' for more details > > configure exiting with result code 77 > > > > > > > > -- Franco Gastón Pellegrini config.log Description: Binary data
Re: RFR: JDK-8213339 Update precompiled.hpp with headers based on current frequency
On 3/11/2018 10:09 PM, David Holmes wrote: Looks okay - thanks for doing all the experiments! (Though I'm still curious what happens if you recompile individual header files :) ). s/recompile/precompile/ :) David 25 // Precompiled headers are turned off for Sun Studio, May as well change to Solaris Studio if you're going to fix the typo :) Thanks. David On 3/11/2018 7:06 PM, Magnus Ihse Bursie wrote: The reasons for the current set of files included in precompiled.hpp is somewhat lost in the mists of history. However, it is clear that it is not optimal. This patch replaces the current set with a new set, based on how often a header file is included in a C++ file. This selection contains all header files that are included by at least 130 C++ files. Testing has shown that this is around the optimal value -- include many more, and too many "innocent" files get hurt by unneeded work, leave out many more, and we miss out on optimization possibilities. The same set turned out to work well for both clang and gcc. However, files named "*.inline.hpp" did hurt rather than help performance, so those have been left out. For visual studio, the same set was also optimal, as long as the inline files were included. Presumably, visual studio is better than gcc/clang on handling precompiled headers containing inlined code. Here are some rough comparisons from our internal CI system, for building the target "hotspot" from scratch. macosx-x64: old: 00:05:00 new: 00:03:47 linux-x64: old: 00:05:43 new: 00:04:51 windows-x64: old: 00:05:18 new: 00:04:33 linux-aarch64: old: 00:07:57 new: 00:03:48 Bug: https://bugs.openjdk.java.net/browse/JDK-8213339 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8213339-update-precompiled-headers/webrev.01 /Magnus
Re: RFR: JDK-8213339 Update precompiled.hpp with headers based on current frequency
Looks okay - thanks for doing all the experiments! (Though I'm still curious what happens if you recompile individual header files :) ). 25 // Precompiled headers are turned off for Sun Studio, May as well change to Solaris Studio if you're going to fix the typo :) Thanks. David On 3/11/2018 7:06 PM, Magnus Ihse Bursie wrote: The reasons for the current set of files included in precompiled.hpp is somewhat lost in the mists of history. However, it is clear that it is not optimal. This patch replaces the current set with a new set, based on how often a header file is included in a C++ file. This selection contains all header files that are included by at least 130 C++ files. Testing has shown that this is around the optimal value -- include many more, and too many "innocent" files get hurt by unneeded work, leave out many more, and we miss out on optimization possibilities. The same set turned out to work well for both clang and gcc. However, files named "*.inline.hpp" did hurt rather than help performance, so those have been left out. For visual studio, the same set was also optimal, as long as the inline files were included. Presumably, visual studio is better than gcc/clang on handling precompiled headers containing inlined code. Here are some rough comparisons from our internal CI system, for building the target "hotspot" from scratch. macosx-x64: old: 00:05:00 new: 00:03:47 linux-x64: old: 00:05:43 new: 00:04:51 windows-x64: old: 00:05:18 new: 00:04:33 linux-aarch64: old: 00:07:57 new: 00:03:48 Bug: https://bugs.openjdk.java.net/browse/JDK-8213339 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8213339-update-precompiled-headers/webrev.01 /Magnus
Re: RFR: JDK-8213339 Update precompiled.hpp with headers based on current frequency
On 11/03/2018 10:06 AM, Magnus Ihse Bursie wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8213339 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8213339-update-precompiled-headers/webrev.01 This looks good to me. Thanks, -Aleksey
RFR: JDK-8213339 Update precompiled.hpp with headers based on current frequency
The reasons for the current set of files included in precompiled.hpp is somewhat lost in the mists of history. However, it is clear that it is not optimal. This patch replaces the current set with a new set, based on how often a header file is included in a C++ file. This selection contains all header files that are included by at least 130 C++ files. Testing has shown that this is around the optimal value -- include many more, and too many "innocent" files get hurt by unneeded work, leave out many more, and we miss out on optimization possibilities. The same set turned out to work well for both clang and gcc. However, files named "*.inline.hpp" did hurt rather than help performance, so those have been left out. For visual studio, the same set was also optimal, as long as the inline files were included. Presumably, visual studio is better than gcc/clang on handling precompiled headers containing inlined code. Here are some rough comparisons from our internal CI system, for building the target "hotspot" from scratch. macosx-x64: old: 00:05:00 new: 00:03:47 linux-x64: old: 00:05:43 new: 00:04:51 windows-x64: old: 00:05:18 new: 00:04:33 linux-aarch64: old: 00:07:57 new: 00:03:48 Bug: https://bugs.openjdk.java.net/browse/JDK-8213339 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8213339-update-precompiled-headers/webrev.01 /Magnus
Re: Stop using precompiled headers for Linux?
On 2018-10-30 20:21, Erik Joelsson wrote: Last I checked, it did provide significant build speed improvements when building just hotspot, but that could need revisiting. We do have verification of --disable-precompiled-headers (in slowdebug) in builds-tier2 so we normally get notified if this fails. However, Mach5 has not been running since Friday so this particular bug wasn't detected automatically. Looking at the bug, it also failed on Solaris, which would have been caught by tier1 builds. If we decide to keep precompiled headers on by default, maybe we should add a simple no-PCH verification task in tier1? It only needs to build hotspot, so it should be quick. /Magnus /Erik On 2018-10-30 10:26, Ioi Lam wrote: Is there any advantage of using precompiled headers on Linux? It's on by default and we keep having breakage where someone would forget to add #include. The latest instance is JDK-8213148. I just turn on precompiled headers explicitly in all my builds. I don't see any difference in build time (at least not significant enough for me to bother). Should we disable it by default on Linux? Thanks - Ioi
Re: compiling openJdk 11 on windows 7 32bits fail
Have you tried running /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl from the same prompt you ran configure to see what happens? It seems to have located a compiler but fails to run it. There is also a second log file, config.log, generated by autoconf. It will hopefully contain output from the failed run of CL, and the complete command line it used when it concluded that the C compiler cannot create executables. /Magnus On 2018-11-03 02:50, Franco Gastón Pellegrini wrote: Hello, When I try to compìle OpenJDK 11, I get an error. I tried using visual studio 2015 and 2017 with the same error. *Note that compiling OpenJDK 9 and 10 work just fine.* I attached the log, but the error is: ** ** Visual Studio 2017 Developer Command Prompt v15.8.9 ** Copyright (c) 2017 Microsoft Corporation ** [vcvarsall.bat] Environment initialized for: 'x86' configure: Setting extracted environment variables checking for Visual Studio variables... ok configure: Rewriting ipath to "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include" configure: Rewriting ipath to "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um" configure: Rewriting ipath to "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt" configure: Rewriting ipath to "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared" configure: Rewriting ipath to "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um" configure: Rewriting ipath to "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt" configure: Rewriting ipath to "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt" configure: Rewriting libpath to "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86" configure: Rewriting libpath to "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86" configure: Rewriting libpath to "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86" configure: Rewriting libpath to "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86" checking for cl... /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl configure: Rewriting CC to "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl" checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.15.26732.1 [Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26732.1 for x86] checking whether the C compiler works... no configure: error: in `/home/Franco/Java/jdk11': configure: error: C compiler cannot create executables See `config.log' for more details configure exiting with result code 77
