Can you provide some details about your toolchain, processor and os plus a dump of the native instructions around the SEGV. This might give us enough info to be able to figure out what’s going on.
Bob. > On Oct 24, 2017, at 1:21 PM, Peter Budai <peterbu...@hotmail.com> wrote: > > I get that error running in the debugger but also running without/outside of > the debugger as well. > > I saw the comment in the code about generating SEGV in function > generate_get_cpu_info(), however the debugger can execute that, and the SEGV > I experience is coming later in the VM_Version::get_processor_features() > function > > Peter > > From: Bob Vandette <mailto:bob.vande...@oracle.com> > Sent: Tuesday, October 24, 2017 6:28 PM > To: Peter Budai <mailto:peterbu...@hotmail.com> > Cc: David Holmes <mailto:david.hol...@oracle.com>; Erik Joelsson > <mailto:erik.joels...@oracle.com>; Magnus Ihse Bursie > <mailto:magnus.ihse.bur...@oracle.com>; build-dev@openjdk.java.net > <mailto:build-dev@openjdk.java.net> > Subject: Re: Building OpenJDK9 on MSYS2 > > Was this a SEGV while you were running the debugger? > > There is an intentional SEGV generated. This is used to determine if we can > use some of newer > CPU features. Try to allow the SEGV to continue to see if you run normally. > > Bob. > > > > On Oct 24, 2017, at 11:37 AM, Peter Budai <peterbu...@hotmail.com > > <mailto:peterbu...@hotmail.com>> wrote: > > > > It seems that the compile is progressing well, I have 49 executables/tools > > and 38 compiled shared libraries already in the JDK folder. > > > > I have tried to run the product with the simplest ‘java -version’ command, > > however I get a SIGSEGV at get_cpu_info_stub() in vm_version_x86.cpp, > > VM_Version::get_processor_features() > > > > get_cpu_info_stub(&_cpuid_info); > > > > Thread 5 received signal SIGSEGV, Segmentation fault. > > 0x000000002d9a072f in ?? () > > > > I can debug using gdb, but unfortunately this is pure ASM, and my knowledge > > on this is close to 0. > > > > Any idea help or pointer how could I tackle this? > > > > Peter > > > > From: David Holmes<mailto:david.hol...@oracle.com > > <mailto:david.hol...@oracle.com>> > > Sent: Sunday, October 15, 2017 10:37 PM > > To: Peter Budai<mailto:peterbu...@hotmail.com > > <mailto:peterbu...@hotmail.com>>; Erik > > Joelsson<mailto:erik.joels...@oracle.com > > <mailto:erik.joels...@oracle.com>>; Magnus Ihse > > Bursie<mailto:magnus.ihse.bur...@oracle.com > > <mailto:magnus.ihse.bur...@oracle.com>> > > Cc: build-dev@openjdk.java.net > > <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > > <mailto:build-dev@openjdk.java.net>> > > Subject: Re: Building OpenJDK9 on MSYS2 > > > > On 16/10/2017 12:41 AM, Peter Budai wrote: > >> A quick status update: > >> > >> * Hotspot successfully compiled without warnings > >> * I’d like to run the unit tests, but as I see ‘make check’ does not > >> work, and gtestlauncher expects a command line parameter jdk. Tried to > >> look up some documentation on this, but have not found. So the question > >> is: how can I run unit tests for hotspot? Do I need also JDK compiled for > >> that? Or the bootJDK is good enough? Any help would be appreciated. > > > > Hotspot has to be tested as part of a full JDK - you can't load the JVM > > without having the "J" part :) > > > > You should be able to drop your built dll into an existing JDK 9 windows > > JDK and test it that way. > > > > David > > ----- > > > >> * Also I’m making progress on compiling jdk, but there are some very > >> interesting solutions on windows linking which makes a bit more difficult > >> to compile with gcc: LIBS_windows contains sometimes simple library names > >> (which I believe is correct) and other times library names with full path > >> (which I believe is not the best solution). I’m trying to rework those > >> places and use simple library names and passing search path for libraries > >> -L<path> (for gcc toolchain) and /LIBPATH:<path> (for Microsoft > >> toolchain). Also I was surprised by a few manual function name exports… > >> * jdk code base contains apparently more MSVC specific part, many > >> places casts/lack of casts are generating errors, static attributes were > >> missing etc. a bit tedious work. > >> > >> P. > >> > >> From: Erik Joelsson<mailto:erik.joels...@oracle.com > >> <mailto:erik.joels...@oracle.com>> > >> Sent: Wednesday, October 11, 2017 4:16 PM > >> To: Magnus Ihse Bursie<mailto:magnus.ihse.bur...@oracle.com > >> <mailto:magnus.ihse.bur...@oracle.com>>; Peter > >> Budai<mailto:peterbu...@hotmail.com <mailto:peterbu...@hotmail.com>> > >> Cc: build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net>> > >> Subject: Re: Building OpenJDK9 on MSYS2 > >> > >> Hello, > >> > >> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: > >> > >> For gcc, we let the compiler generate the .d file. For the Microsoft tool > >> chain, we use a clever sed script to extract and create it ourself. > >> > >> I think that logic is checking for "Windows", not "Microsoft". That might > >> be your cause of trouble. > >> > >> Look in NativeCompilation.gmk. > >> > >> That was my initial thought as well, but we do correctly check for > >> microsoft. Also it's not the .d files that are the problem. As Peter just > >> wrote, they look fine. It's the .d.target files which we create using the > >> same technique on all platforms. What we don't account for is the compiler > >> putting Windows mixed paths in the .d files. > >> > >> /Magnus > >> > >> 11 okt. 2017 kl. 14:43 skrev Peter Budai <peterbu...@hotmail.com > >> <mailto:peterbu...@hotmail.com><mailto:peterbu...@hotmail.com > >> <mailto:peterbu...@hotmail.com>>>: > >> Hi Erik, > >> > >> The .d file looks like this: > >> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: > >> \ > >> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp \ > >> > >> I have checked .d.targets file, and looks like it has the first line has > >> not been deleted, and the file names below are also wrong: > >> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj > >> : : > >> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : > >> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : > >> > >> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by the > >> “C:/” > >> -e 's/^[^:]*: *//' > >> > >> Yes, that does indeed look like the problem. I suppose the regexp is > >> unnecessarily strict. It should be ok to rewrite it as something like this: > >> -e 's/^.*: *//' > >> > >> Basically just make sure it ends with : and any number of spaces. > >> > >> /Erik > >> > >> > >> > >> Peter > >> > >> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986 > >> <https://go.microsoft.com/fwlink/?LinkId=550986>> for Windows 10 > >> > >> From: Erik Joelsson<mailto:erik.joels...@oracle.com > >> <mailto:erik.joels...@oracle.com>> > >> Sent: Wednesday, October 11, 2017 12:16 PM > >> To: Peter Budai<mailto:peterbu...@hotmail.com > >> <mailto:peterbu...@hotmail.com>>; Magnus Ihse > >> Bursie<mailto:magnus.ihse.bur...@oracle.com > >> <mailto:magnus.ihse.bur...@oracle.com>>; build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net>> > >> Subject: Re: Building OpenJDK9 on MSYS2 > >> > >> > >> Hello Peter, > >> > >> On 2017-10-11 00:18, Peter Budai wrote: > >> Thanks Magnus & Erik > >> > >> First thanks for your support and kind words! > >> > >> Magnus, I have checked .bash_profile, .bashrc but they seem to be empty > >> (everything is commented out). You can check with a default MSYS2 install, > >> I have not changed these files at all. If you find thee something specific > >> I can give a try here as well. > >> > >> Let me give also a quick status update, where am I with building hotspot: > >> · I guess its still the beginning, but I have managed to compile > >> jvm.dll with almost 700 object file: with debug info the dll is around 700 > >> MB 😊 > >> · I made only surgical, minimal changes to the source, and so far it > >> looks reasonable. I have encountered 3 scenarios where changes were > >> necessary: > >> o When in makefiles conditionals were using assuming that if target_os > >> is windows then it is visual studio compiler/linker. Obviously these > >> conditionals had to be reviewed in a few places and if necessary were > >> changes to check the toolchain=Microsoft > >> These are not surprising and should be pretty straight forward to fix and > >> it seems you know what to do. > >> > >> > >> · > >> o I got a few warnings as gcc 7.2 uncovered some code problems in > >> windows specific codes, where before that MSVC I guess did not say a word… > >> To get around this you can configure with --disable-warnings-as-errors > >> until you get things working properly. This is commonly needed when using > >> compiler versions that we normally don't use. > >> > >> > >> · > >> o And I had like 6-7 places where the code was using MSVC specific __try > >> … __except structures which gcc does not know. Do you have a suggestion > >> how to approach them? I can do ugly #ifdefs (I would avoid that) but I > >> have also seen some solutions to replace them with a code which gcc can > >> compile > >> (http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh > >> <http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh> > >> ) – but before doing that though I would ask first you on the purpose of > >> those > >> This kind of question is probably best to bring to the hotspot mailing > >> list. > >> · What bothers me is that I was not able to do incremental builds: > >> when an error occurs, and build stops, then after making change in the CPP > >> source the build cannot continue, I always got an error message: > >> > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.d.targets:1: > >> *** missing target pattern. Stop. > >> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 > >> > >> If I do a ‘make clean’ and restart the build then it nicely compiles. > >> > >> Question 1: Is there a way to resume such builds without ‘make clean’? > >> Well, incremental builds is supposed to work well. We have several extra > >> tricks in there to handle cases where normal make builds would fail. The > >> *.d.targets files is one such trick and it seems to backfire for you. The > >> contents of that file should be something like: > >> > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : > >> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : > >> > >> Basically an empty rule for each dependency for the corresponding object > >> file. Declaring these rules makes it possible to delete source files > >> without having to build clean. It seems your file is not generated > >> correctly so please have a look inside it. The file is in > >> make/common/NativeCompilation.gmk, look for DEPENDENCY_TARGET_SED_PATTERN. > >> > >> > >> > >> Question 2: What would be the best way to submit/share the patches for > >> your thorough review? > >> > >> Well, first of all, have you signed the OCA? > >> > >> As for publishing patches and reviews, there is a bit of chicken and egg > >> problem. Once you become an "author" in any of the OpenJDK projects, you > >> get a user name and should be able to publish reviews on > >> cr.openjdk.java.net > >> <http://cr.openjdk.java.net/><http://cr.openjdk.java.net > >> <http://cr.openjdk.java.net/>>. Before that, if the patch is small, it can > >> be posted inline in an email to the list. If it's large, you will need a > >> current OpenJDK user to host it for you. At least that's how I understand > >> it. Hopefully someone who knows the process better can chime in here. > >> > >> I should also let you know that getting this into JDK 9 is most likely not > >> going to happen. AFAIK we are only doing security updates for 9. It would > >> have to go into the currently active release. I should also warn you that > >> new ports generally need a certain amount of backing to be accepted. It > >> may be that this would have to live in a porting side project. Hopefully > >> someone who knows this better can chime in here as well. > >> > >> /Erik > >> > >> > >> P. > >> > >> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986 > >> <https://go.microsoft.com/fwlink/?LinkId=550986>> for Windows 10 > >> > >> From: Magnus Ihse Bursie<mailto:magnus.ihse.bur...@oracle.com > >> <mailto:magnus.ihse.bur...@oracle.com>> > >> Sent: Tuesday, October 10, 2017 10:04 AM > >> To: Peter Budai<mailto:peterbu...@hotmail.com > >> <mailto:peterbu...@hotmail.com>>; Erik > >> Joelsson<mailto:erik.joels...@oracle.com > >> <mailto:erik.joels...@oracle.com>>; build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net>> > >> Subject: Re: Building OpenJDK9 on MSYS2 > >> > >> On 2017-10-07 10:14, Peter Budai wrote: > >> The configure of OpenJDK overwrites the SHELL. Actually it is using bash, > >> but for the arguments it was using “-e -o pipefail”. I have figured that > >> for MSYS2 bash what is needed as bash arguments is “-e -l -c -o pipefail” > >> > >> That looks like solving this problem, and now the real issues are > >> surfacing. > >> > >> FWIW, "-l" makes bash behave like a login shell. Most likely you are > >> changing bash's behavior in one of your login scripts, and that change is > >> what's really needed. > >> > >> /Magnus > >> > >> > >> > >> > >> > >> Peter > >> > >> From: Peter Budai<mailto:peterbu...@hotmail.com > >> <mailto:peterbu...@hotmail.com>> > >> Sent: Friday, October 6, 2017 6:43 PM > >> To: Magnus Ihse Bursie<mailto:magnus.ihse.bur...@oracle.com > >> <mailto:magnus.ihse.bur...@oracle.com>>; Erik > >> Joelsson<mailto:erik.joels...@oracle.com > >> <mailto:erik.joels...@oracle.com>>; build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net>> > >> Subject: RE: Building OpenJDK9 on MSYS2 > >> > >> Magnus, > >> > >> I have followed your suggestion and removed the fixpath prefixes from gcc > >> related compile tools, and left only the fixpath prefix _only_ for the > >> Boot JDK related tools in place. > >> > >> 1) As I follow the process, all java and javac related compile steps > >> are running properly > >> 2) When the process reaches gcc related steps I got the error message > >> at the same place as before (no fixpath). If I execute that command from > >> the bash prompt, it creates the output: > >> > >> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' > >> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template > >> && /C/msys64/mingw64/bin/gcc -E -x c > >> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template > >> 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | > >> /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e > >> 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e > >> 's/PREFIX_//' -e 's/^#.*//' ) > > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java > >> > >> As I have mentioned the parameters are replaced by the bash automatically > >> 3) Then build continues, then little later stops at a super simple > >> command: > >> > >> mv > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp > >> > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java > >> Needless to say, the ByteBuffer.java.tmp file DOES exist. And > >> running the above command from the bash works, and build continues. > >> 4) A few similar cases (stops) with DirectByteBuffer and > >> DirectByteBufferR > >> > >> > >> Currently I try to explore how that might relate to the MSYS2 bash and > >> make, somehow it behaves differently > >> > >> If you have any other suggestion, let me know. > >> > >> Best regards, > >> > >> Peter > >> > >> From: Peter Budai<mailto:peterbu...@hotmail.com > >> <mailto:peterbu...@hotmail.com>> > >> Sent: Thursday, October 5, 2017 3:52 PM > >> To: Magnus Ihse Bursie<mailto:magnus.ihse.bur...@oracle.com > >> <mailto:magnus.ihse.bur...@oracle.com>>; Erik > >> Joelsson<mailto:erik.joels...@oracle.com > >> <mailto:erik.joels...@oracle.com>>; build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net>> > >> Subject: RE: Building OpenJDK9 on MSYS2 > >> > >> Hi Magnus, > >> > >> So first of all, here is the current patch, which I was not able to > >> attach: https://pastebin.com/pwT4Ynxc <https://pastebin.com/pwT4Ynxc> > >> > >>>> That's surprising, since gcc is prefixed with fixpath, which it should > >>>> not. > >> Actually you DO need fixpath IMHO. > >> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), which is > >> a fully functional Windows executable, which expects Windows formatted > >> path arguments. > >> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see that > >> patch), none of the command line arguments are converted from the unix > >> path to Windows, but fixpath does that conversion. There is a wiki > >> describing more details on this: > >> https://github.com/msys2/msys2/wiki/Porting#user-content-filesystem-namespaces > >> > >> <https://github.com/msys2/msys2/wiki/Porting#user-content-filesystem-namespaces> > >> > >> > >> > >>>> I have a hard time believing this is a race condition. On the other > >>>> hand, this stuff is weird, we're misusing the C preprocessor to process > >>>> defines in java code, so I'm not surprised it breaks down. > >>>> I don't know why it succeeded when run on the command line, though. > >> When I execute that command from the bash command line there is no EXPORT > >> MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic conversion of > >> the arguments. Maybe it has something to do how fixpath does CreateProcess? > >> > >> Does that help? > >> > >> Best regards, > >> > >> Peter > >> > >> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986 > >> <https://go.microsoft.com/fwlink/?LinkId=550986>> for Windows 10 > >> > >> From: Magnus Ihse Bursie<mailto:magnus.ihse.bur...@oracle.com > >> <mailto:magnus.ihse.bur...@oracle.com>> > >> Sent: Thursday, October 5, 2017 12:13 PM > >> To: Peter Budai<mailto:peterbu...@hotmail.com > >> <mailto:peterbu...@hotmail.com>>; Erik > >> Joelsson<mailto:erik.joels...@oracle.com > >> <mailto:erik.joels...@oracle.com>>; build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net>> > >> Subject: Re: Building OpenJDK9 on MSYS2 > >> > >> > >> On 2017-10-05 11:59, Peter Budai wrote: > >> Hi Magnus and Erik, > >> > >> I really appreciate your quick feedback. I assumed that it won’t be easy, > >> but I just don’t feel I should give up now - maybe later when I see the > >> real scale of work. So bear with me for a time being. > >> > >> Attached is a patch which already includes Magnus’ changes, plus a few > >> which I have added: > >> · basically enabling gcc for windows, > >> · and modifying a logic for compiling fixpath (before that it was > >> using hard-coded MS VSC compile flags) > >> > >> Actually, you must make sure fixpath is *not* used for the toolchain, > >> since gcc uses unix style paths. > >> (However, other tools such as java will still need it.) > >> > >> > >> > >> > >> > >> > >> So here is what I have as the result of configure: > >> ==================================================== > >> The existing configuration has been successfully updated in > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release > >> using configure arguments '--disable-freetype-bundling > >> --disable-javac-server'. > >> > >> Configuration summary: > >> * Debug level: release > >> * HS debug level: product > >> * JDK variant: normal > >> * JVM variants: server > >> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 > >> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) > >> > >> Tools summary: > >> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) > >> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime > >> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM > >> (build 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) > >> * Toolchain: gcc (GNU Compiler Collection) > >> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) > >> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) > >> > >> Build performance summary: > >> * Cores to use: 4 > >> * Memory limit: 16216 MB > >> > >> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual > >> Studio on this machine) > >> > >> Now for the details of the config log, you can see here: > >> https://pastebin.com/MN2ZYcHH <https://pastebin.com/MN2ZYcHH> > >> > >> And about the build process and the error I get: > >> > >> $ make JOBS=1 > >> Building target 'default (exploded-image)' in configuration > >> 'windows-x86_64-normal-server-release' > >> Compiling 8 files for BUILD_TOOLS_LANGTOOLS > >> Compiling 17 properties into resource bundles for jdk.compiler > >> Parsing 1 properties into enum-like class for jdk.compiler > >> Compiling 19 properties into resource bundles for jdk.javadoc > >> Compiling 12 properties into resource bundles for jdk.jdeps > >> Compiling 7 properties into resource bundles for jdk.jshell > >> Compiling 117 files for BUILD_INTERIM_java.compiler > >> Compiling 396 files for BUILD_INTERIM_jdk.compiler > >> Compiling 61 files for BUILD_INTERIM_jdk.jdeps > >> Compiling 457 files for BUILD_INTERIM_jdk.javadoc > >> Note: Some input files use or override a deprecated API. > >> Note: Recompile with -Xlint:deprecation for details. > >> Compiling 159 files for BUILD_TOOLS_JDK > >> Note: Some input files use unchecked or unsafe operations. > >> Note: Recompile with -Xlint:unchecked for details. > >> make[3]: *** [GensrcMisc.gmk:78: > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java] > >> Error 1 > >> make[3]: *** Deleting file > >> '/C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java' > >> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 > >> > >> ERROR: Build failed for target 'default (exploded-image)' in configuration > >> 'windows-x86_64-normal-server-release' (exit code 2) > >> > >> No indication of failed target found. > >> Hint: Try searching the build log for '] Error'. > >> Hint: See common/doc/building.html#troubleshooting for assistance. > >> > >> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 > >> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 > >> > >> If I run here > >> make JOBS=1 LOG=debug > >> The failing line seems to be this: > >> > >> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' > >> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template > >> && > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe > >> -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x c > >> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template > >> 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | > >> /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e > >> 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e > >> 's/PREFIX_//' -e 's/^#.*//' ) > > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java > >> make[3]: *** [GensrcMisc.gmk:78: > >> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java] > >> Error 1 > >> > >> Now the interesting is: if I copy this line above to the bash prompt, it > >> runs without problem, and the file > >> support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java > >> That's surprising, since gcc is prefixed with fixpath, which it should not. > >> > >> I have a hard time believing this is a race condition. On the other hand, > >> this stuff is weird, we're misusing the C preprocessor to process defines > >> in java code, so I'm not suprised it breaks down. I don't know why it > >> succeeded when run on the command line, though. My suggestion is to just > >> do some quick and dirty hack around this: take the file you manage to > >> generate and just copy it in during the build instead. If you can get > >> round this, you might start seeing some *real* problems. :-) > >> > >> Also, my suggestion is that you try running "make hotspot" to cut to the > >> chase. Compiling hotspot will likely be the hardest thing. Or even "make > >> -k hotspot" to get an assessment of the amount of work ahead of you. > >> > >> /Magnus > >> Is produced. > >> > >> Then I can again issue > >> make JOBS=1 LOG=debug > >> > >> And the compile process is being continued, until a similar error pops up > >> with a different generated file. I have an assumption that this happens > >> because make is still running parallel jobs, despite JOBS=1 but I’m not > >> sure. > >> > >> How could I best tackle this? > >> > >> Thank you and best regards, > >> > >> Peter > >> > >> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986 > >> <https://go.microsoft.com/fwlink/?LinkId=550986>> for Windows 10 > >> > >> From: Magnus Ihse Bursie<mailto:magnus.ihse.bur...@oracle.com > >> <mailto:magnus.ihse.bur...@oracle.com>> > >> Sent: Thursday, October 5, 2017 11:33 AM > >> To: Erik Joelsson<mailto:erik.joels...@oracle.com > >> <mailto:erik.joels...@oracle.com>>; Peter > >> Budai<mailto:peterbu...@hotmail.com <mailto:peterbu...@hotmail.com>>; > >> build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > >> <mailto:build-dev@openjdk.java.net>> > >> Subject: Re: Building OpenJDK9 on MSYS2 > >> > >> On 2017-10-05 10:10, Erik Joelsson wrote: > >>> Hello Peter, > >>> > >>> > >>> On 2017-10-04 21:15, Peter Budai wrote: > >>>> Hi Magnus, > >>>> > >>>> Thanks for the quick reply I’ll check these patches with msys2. > >>>> > >>>> Let me specify with more details what I’d like to achieve: I’d like > >>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc toolchain. > >>>> (I’m not sure how familiar are you with MSYS2, but there are 3 > >>>> different environments: MSYS2, MINGW32 and MINGW64). In theory > >>>> MINGW64 with gcc is the closes you can get on Windows platform as a > >>>> gcc unix like build environment, which produces still a native 64-bit > >>>> executable on Windows. > >>>> > >>>> I’m not very familiar with OpenJDK yet, so therefore I’d like to hear > >>>> your opinion: how realistic is that? > >>> Sorry to disappoint, but I would say that requires major work. There > >>> is a strong historic assumption that windows builds are done using > >>> Visual Studio. We have abstracted away some of it in configure (see > >>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler > >>> environment for a Windows build. The native sources are also bound to > >>> make a lot of such assumptions. I would expect the changes needed to > >>> be in the thousands of lines of code. > >> > >> I agree that it requires hard work (even if "thousands" might be an > >> overestimation I think, but "hundreds" is not enough, so it's the right > >> magnitude). On the other hand, it would be really good if we did sort > >> things out, so that we had proper conditions based on OS vs > >> compiler/toolchain. > >> > >> If you really want to start, the first thing is to patch toolchain.m4 to > >> VALID_TOOLCHAINS_windows="microsoft gcc" > >> and then call configure using "bash configure --with-toolchain-type=gcc". > >> > >> As Erik, I doubt you will come very far before things starts tumbling down. > >> > >>> > >>> When we say supporting the build in msys2 instead of cygwin, we just > >>> mean using msys2 as the unix emulating layer for our tools like > >>> make/bash/grep/sed etc. > >>> > >>> One think I have done successfully is running the build in WSL > >>> (Windows Subsystem for Linux), but that isn't all that helpful as WSL > >>> for practical purposes is more or less like running Linux in a VM, so > >>> the build sees a Linux system and builds a Linux binary. > >>>> As a side note: with MINGW64 I have managed to run configure phase > >>>> successfully for OpenJDK. The compile process has also started and > >>>> went for a while, but interestingly I run into some kind of race > >>>> conditions as make stopped with an error. Using LOG=debug I have fond > >>>> the failing line and then copying the failed command and pasting it > >>>> to the bash prompt it successfully generated the output target, and > >>>> then the build process run further when a similar situation happened. > >>>> Also pasting the failed command run in the bash without any problem, > >>>> and build continued… until the next. > >>> Without seeing the errors I can't say much. I very much doubt that you > >>> are running with gcc as the compiler though. Configure isn't easily > >>> fooled into using a different compiler to what it prefers, and I would > >>> expect things to crash and burn pretty early if you actually did. > >>> > >>> /Erik > >>>> > >>>> I have tried to run make JOBS=1, but did not help, strangely I have > >>>> still seen in the log make[3] and make[4] logs which suggested that > >>>> there are more than one make jobs were running. Also tried .configure > >>>> --with-output-sync=recurse without success (same symptoms) > >>>> > >>>> Let me know your thoughts. > >>>> > >>>> Best regards, > >>>> > >>>> Peter > >>>> > >>>> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986 > >>>> <https://go.microsoft.com/fwlink/?LinkId=550986>> for > >>>> Windows 10 > >>>> > >>>> From: Magnus Ihse Bursie<mailto:magnus.ihse.bur...@oracle.com > >>>> <mailto:magnus.ihse.bur...@oracle.com>> > >>>> Sent: Wednesday, October 4, 2017 1:04 AM > >>>> To: Peter Budai<mailto:peterbu...@hotmail.com > >>>> <mailto:peterbu...@hotmail.com>>; > >>>> build-dev@openjdk.java.net > >>>> <mailto:build-dev@openjdk.java.net><mailto:build-dev@openjdk.java.net > >>>> <mailto:build-dev@openjdk.java.net>><mailto:build-dev@openjdk.java.net > >>>> <mailto:build-dev@openjdk.java.net>><mailto:build-dev@openjdk.java.net > >>>> <mailto:build-dev@openjdk.java.net>> > >>>> Subject: Re: Building OpenJDK9 on MSYS2 > >>>> > >>>> Actually, it wasn't so much remaining trouble. :-) I fired up msys2 and > >>>> checked out where I left off. It turned out that the remaining snag was > >>>> that msys2 tries to convert command lines automatically, from "unix" > >>>> style paths to "windows" style paths. Unfortunately, it does not do this > >>>> very well and it breaks all sorts of things. We already have a FIXPATH > >>>> solution in place which deals with this, so basically all I had to do > >>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, this > >>>> broke our cygpath replacement hack (!) so I had to disable it there. > >>>> Sigh. Anyway, with those fixes it ran and worked well. (I also > >>>> discovered and fixed a bug related to how we set up the FIXPATH variable > >>>> on msys, but it only triggers in certain circumstances). > >>>> > >>>> With this patch I now jdk9 seems to build fine on msys2. It should apply > >>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll try to > >>>> get it in in jdk10. > >>>> > >>>> Here's the patch if you want to apply it yourself: > >>>> > >>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 > >>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 2017 > >>>> +0000 > >>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 2017 > >>>> +0200 > >>>> @@ -42,7 +42,7 @@ > >>>> windows_path=`$CYGPATH -m "$unix_path"` > >>>> $1="$windows_path" > >>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then > >>>> - windows_path=`cmd //c echo $unix_path` > >>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` > >>>> $1="$windows_path" > >>>> fi > >>>> ]) > >>>> @@ -136,6 +136,16 @@ > >>>> fi > >>>> ]) > >>>> > >>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], > >>>> +[ > >>>> + # Take all collected prefixes and turn them into a > >>>> -m/c/foo@/c/bar@... command line > >>>> + # @ was chosen as separator to minimize risk of other tools messing > >>>> around with it > >>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ > >>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` > >>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` > >>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" > >>>> +]) > >>>> + > >>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], > >>>> [ > >>>> path="[$]$1" > >>>> @@ -143,7 +153,7 @@ > >>>> new_path="$path" > >>>> if test "x$has_colon" = x; then > >>>> # Not in mixed or Windows style, start by that. > >>>> - new_path=`cmd //c echo $path` > >>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` > >>>> fi > >>>> > >>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) > >>>> @@ -155,6 +165,8 @@ > >>>> > >>>> # Save the first 10 bytes of this path to the storage, so fixpath > >>>> can work. > >>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" > >>>> "${new_path:0:10}") > >>>> + # We might need to re-evaluate FIXPATH. > >>>> + BASIC_MSYS_UPDATE_FIXPATH > >>>> ]) > >>>> > >>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], > >>>> @@ -293,7 +305,7 @@ > >>>> # Do not save /bin paths to all_fixpath_prefixes! > >>>> else > >>>> # Not in mixed or Windows style, start by that. > >>>> - new_path=`cmd //c echo $new_path` > >>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` > >>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) > >>>> # Output is in $new_path > >>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) > >>>> @@ -302,6 +314,8 @@ > >>>> > >>>> # Save the first 10 bytes of this path to the storage, so fixpath > >>>> can work. > >>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" > >>>> "${new_path:0:10}") > >>>> + # We might need to re-evaluate FIXPATH. > >>>> + BASIC_MSYS_UPDATE_FIXPATH > >>>> fi > >>>> ]) > >>>> > >>>> @@ -347,6 +361,10 @@ > >>>> WINDOWS_ENV_VENDOR='msys' > >>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" > >>>> > >>>> + # Prohibit msys2 path conversion from trying to be "intelligent", > >>>> and rely > >>>> + # on fixpath instead. > >>>> + export MSYS2_ARG_CONV_EXCL="*" > >>>> + > >>>> AC_MSG_CHECKING([msys root directory as unix-style path]) > >>>> # The cmd output ends with Windows line endings (CR/LF), the grep > >>>> command will strip that away > >>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` > >>>> @@ -391,10 +409,7 @@ > >>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then > >>>> # Take all collected prefixes and turn them into a > >>>> -m/c/foo@/c/bar@... command line > >>>> # @ was chosen as separator to minimize risk of other tools > >>>> messing around with it > >>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ > >>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` > >>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` > >>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" > >>>> + BASIC_MSYS_UPDATE_FIXPATH > >>>> fi > >>>> FIXPATH_SRC_W="$FIXPATH_SRC" > >>>> FIXPATH_BIN_W="$FIXPATH_BIN" > >>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub > >>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 > >>>> 2017 +0000 > >>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 > >>>> 2017 +0200 > >>>> @@ -30,7 +30,7 @@ > >>>> DIR=`dirname $0` > >>>> > >>>> # First, filter out everything that doesn't begin with "aarch64-" > >>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then > >>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then > >>>> . $DIR/autoconf-config.sub "$@" > >>>> # autoconf-config.sub exits, so we never reach here, but just in > >>>> # case we do: > >>>> @@ -38,13 +38,17 @@ > >>>> fi > >>>> > >>>> while test $# -gt 0 ; do > >>>> - case $1 in > >>>> + case $1 in > >>>> -- ) # Stop option processing > >>>> shift; break ;; > >>>> aarch64-* ) > >>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` > >>>> sub_args="$sub_args $config" > >>>> shift; ;; > >>>> + *-msys ) > >>>> + config=`echo $1 | sed 's/msys/mingw32/'` > >>>> + sub_args="$sub_args $config" > >>>> + shift; ;; > >>>> - ) # Use stdin as input. > >>>> sub_args="$sub_args $1" > >>>> shift; break ;; > >>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in > >>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 +0000 > >>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 +0200 > >>>> @@ -120,6 +120,13 @@ > >>>> # On Windows, the Visual Studio toolchain needs the PATH to be > >>>> adjusted > >>>> # to include Visual Studio tools (this needs to be in cygwin/msys > >>>> style). > >>>> export PATH:=@VS_PATH@ > >>>> + > >>>> +endif > >>>> + > >>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) > >>>> + # On msys2, prohibit msys path conversion from trying to be > >>>> + # "intelligent", and rely on fixpath instead. > >>>> + export MSYS2_ARG_CONV_EXCL:=* > >>>> endif > >>>> > >>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ > >>>> > >>>> /Magnus > >>>> > >>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: > >>>>> I gave msys2 a shot some time ago, but it ended up too much trouble. > >>>>> I'll share some of my notes from that attempt, for what it's worth. > >>>>> > >>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and > >>>>> packages where to find them: > >>>>> cmp: msys/diffutils > >>>>> tar: msys/tar > >>>>> make: msys/make > >>>>> unzip: msys/unzip > >>>>> zip: msys/zip > >>>>> > >>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as > >>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" config.sub > >>>>> to report msys2 similar to msys. (Opinions, including my own :-) may > >>>>> vary if this really is the best way..) > >>>>> > >>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub > >>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 10:15:41 > >>>>> 2017 +0100 > >>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 05:00:25 > >>>>> 2017 -0700 > >>>>> @@ -30,7 +30,7 @@ > >>>>> DIR=`dirname $0` > >>>>> > >>>>> # First, filter out everything that doesn't begin with "aarch64-" > >>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then > >>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then > >>>>> . $DIR/autoconf-config.sub "$@" > >>>>> # autoconf-config.sub exits, so we never reach here, but just in > >>>>> # case we do: > >>>>> @@ -45,6 +45,10 @@ > >>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` > >>>>> sub_args="$sub_args $config" > >>>>> shift; ;; > >>>>> + *-msys ) > >>>>> + config=`echo $1 | sed 's/msys/mingw32/'` > >>>>> + sub_args="$sub_args $config" > >>>>> + shift; ;; > >>>>> - ) # Use stdin as input. > >>>>> sub_args="$sub_args $1" > >>>>> shift; break ;; > >>>>> > >>>>> If I remember correctly, this got me past the configure stage at the > >>>>> time. > >>>>> > >>>>> I don't think it's very hard to get it to work on msys2, I just ran > >>>>> into one snag too many and didn't think msys2 would be used by anyone. > >>>>> > >>>>> /Magnus > >>>>> > >>>>> On 2017-10-03 17:20, Peter Budai wrote: > >>>>>> Hello, > >>>>>> > >>>>>> According to > >>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/common/doc/building.html > >>>>>> > >>>>>> <http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/common/doc/building.html> > >>>>>> > >>>>>> “msys2 and the new Windows Subsystem for Linux (WSL) would likely be > >>>>>> possible to support in a future version but that would require a > >>>>>> community effort to implement” > >>>>>> > >>>>>> I’d like to help making the OpenJDK 9 build working on msys2. What is > >>>>>> the best way to move forward? Is there a similar effort in progress? > >>>>>> > >>>>>> Thank you and best regards, > >>>>>> > >>>>>> Peter > >>>>>> > >>>>>> > >>> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >
