Hi,
You can find the patches here: https://github.com/peterbud/MINGW-packages/tree/openjdk/mingw-w64-openjdk I have managed to build OpenJDK on MSYS2 with gcc, both 32 and 64 bit, but that was obviously the beginning. Around 10% of the test cases were failing so more work would have been needed. However since December I have not worked on that, as (don’t take it personal pls) I have not received feedback on what is the best way to work towards reviewing (and ultimately merging) these changes. Good luck on your journey. Peter Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ________________________________ From: Thomas Stüfe <thomas.stu...@gmail.com> Sent: Tuesday, June 12, 2018 11:49:00 AM To: Magnus Ihse Bursie; jbvernee Cc: build-dev; Peter Budai Subject: Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe I second the advice to get cygwin up and running. Cygwin is the canonical way to build on windows. Unless you have really pressing reasons to use something else, I would use what (almost) everyone else uses. I have my windows build env up and running on a fresh windows machine usually in ~30 minutes. It should not be rocket science. I use both windows 7 and 10 for my work. Some more points, in additions to what the others wrote: - 64bit seems to be the standard: 64bit windows, building 64bit ojdk with a 64bit cygwin. Other configurations may work but are less well tested. Just something to keep in mind. - If you do not trust your windows machine and suspect its software stack may be messed up somehow, there is always the option of installing a fresh copy of windows in a virtual machine, e.g. VirtualBox, and install the tool chain from scratch (cygwin + vistual studio). Best Regards & good luck, Thomas On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > Hi Jorn, > > As you probably have understood by now, porting OpenJDK to msys2 is not just > a simple quick fix. If all you want is to build OpenJDK on your Windows > computer, you are probably better off by trying to fix your Cygwin > installation. From your description, it sounds like you'll need to rebase > it: http://cygwin.wikia.com/wiki/Rebaseall. > > If you want to pursue the msys2 path (and I'd appreciate it; it would be > good to get OpenJDK working on msys again), I suggest you start by looking > at the work that had been done before (but never merged into mainline). See > this conversation: > > http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html > > Peter Budai got the msys part working, but he had more ambitious goals of > getting gcc to build on Windows, which is magnitudes more work, so his patch > was never finished. Nevertheless, he published a patch in [1] which got > stripped by the mailing list. I've put it up here: > > http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch > > It is for jdk9 so it's not possibly to apply out of the box, but you can > probably see what's been done and trying to reimplement it. I think the > "magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which > disables msys2 path mangling. > > Good luck! > > /Magnus > > [1] > http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html > > > > On 2018-06-11 23:26, jbvernee wrote: >> >> Hello, >> >> I have tried the MSYS2_ARG_CONV_EXCL environment variable, thanks for the >> suggestion. It's supposed to be a semi-colon separated list of argument >> prefixes (they have some examples like `/switch;/sdcard;--root=`), so I >> tried setting it to `/out:`, `-Fe` (from the .m4 file) and `/out`, and also >> just the entire path that is being mangled. But none of them worked :( >> (still the same error). >> >> I'm trying to build the amber repo, which I think is parallel with jdk/jdk >> tip? Any ways, there is no autogen.sh in /make/autoconf and anytime I make >> changes to the .m4 file it mentions something about having to regenerate the >> configure file. I can also see the changes I make in >> `/build/.configure-support/generated-configure.sh`, which currently looks >> like this (the part I mentioned): >> >> ``` >> #$RM -rf $FIXPATH_BIN $FIXPATH_DIR >> #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin >> cd $CURDIR >> echo "#####################" here >> #if test ! -x $FIXPATH_BIN; then >> # cd $FIXPATH_DIR >> # $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log >> 2>&1 >> # cd $CURDIR >> #fi >> echo "#####################" there >> >> if test ! -x $FIXPATH_BIN; then >> { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 >> $as_echo "no" >&6; } >> cat $FIXPATH_DIR/fixpath1.log >> as_fn_error $? "Could not create $FIXPATH_BIN" "$LINENO" 5 >> fi >> ``` >> >> Which gives me this output (the last few lines): >> >> ``` >> checking if fixpath can be created... >> ##################### here >> ##################### there >> no >> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64 >> Copyright (C) Microsoft Corporation. All rights reserved. >> configure: error: Could not create >> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/cofixpath.cupport/bin/fixpath.exe >> J:/Projects/openjdk/amber/make/src/native/fixpath.c(49): warning C4477: >> 'fprintf' : format string '%s' requires an argument of type 'char *', but >> variadic argument 3 has type 'LPVOID' >> Microsoft (R) Incremental Linker Version 14.00.24215.1 >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> >> /out:J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe >> fixpath.obj >> LINK : fatal error LNK1104: cannot open file >> 'J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe' >> configure exiting with result code 1 >> ``` >> >> So the changes I'm making seem to be going through... well... at least as >> far as the echo statements go. I also tried using -e on the check that is >> not comment out, but with no different results (I'm also using autoconf 2.69 >> btw). This is kind of a head scratcher éh. I'm calling it a night, I think >> I'll also try taking this up with the msys guys, some other time. >> >> Thanks for the help so far, >> Jorn Vernee >> >> Erik Joelsson schreef op 2018-06-11 22:19: >>> >>> Hello, >>> >>> On 2018-06-11 13:00, jbvernee wrote: >>>> >>>> Hello Erik, >>>> >>>> Thank you for the suggestion. Unfortunately it didn't help. TBH, I've >>>> been banging my head against trying to build the JDK on my machine on and >>>> off for a few months. So at this point I really appreciate any help that >>>> gets me even an inch further, thanks. >>>> >>>> After your suggestion, I have tracked down the call site of the compile >>>> command and checked the paths that are being used in basics_windows.m4 >>>> (line >>>> 406) to compile fixpath.exe: >>>> >>>> ``` >>>> cd $FIXPATH_DIR >>>> $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log >>>> 2>&1 >>>> cd $CURDIR >>>> ``` >>>> They are: >>>> $CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl >>>> $FIXPATH_BIN_W = >>>> J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe >>>> $FIXPATH_DIR = >>>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath >>>> >>>> Note that the second one is a windows style path. I can change that to >>>> use the unix style path, and that does affect the error message, I now see: >>>> `'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'` >>>> as the path in the linker error. But of course the Visual Studios linker >>>> can't do anything with a unix style path. >>>> >>>> What's weird is that either path is working for the C compiler (cl), but >>>> it is being mangled before being passed to the linker, and I can't find >>>> where the linker command is actually being fired off. It seems to be done >>>> by >>>> that same line. I was hoping you could tell me more about that? >>>> >>> AFAIK, we compile fixpath from a single source file directly into an >>> executable, so it's cl that calls link. Somewhere along the way, msys >>> decides to mangle your path argument incorrectly. You could try using >>> MSYS2_ARG_CONV_EXCL to disable the mangling. I don't remember exactly >>> how it works but I know you can affect the mangling using this env >>> variable. >>>> >>>> One other idea I had, but haven't been able to implement, is to check >>>> whether the fixpath tool exists before trying to compile it. That way I >>>> could just compile it manually. I have tried this snippet in >>>> basics_windows.m4 at line 404: >>>> ``` >>>> #$RM -rf $FIXPATH_BIN $FIXPATH_DIR >>>> #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin >>>> cd $CURDIR >>>> if test ! -x $FIXPATH_BIN; then >>>> cd $FIXPATH_DIR >>>> $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log >>>> 2>&1 >>>> cd $CURDIR >>>> fi >>>> ``` >>>> >>>> i.e. check if fixpath.exe exists, otherwise compile it (I don't know the >>>> source language though, so I just copied that from somewhere else). That >>>> didn't work, the check seems to be failing and it's still trying to compile >>>> (and I don't know why, I hope it's not a tabs vs. spaces issue?). I also >>>> tried just commenting that part out completely, but it's STILL trying to >>>> compile. I have no idea why that is happening a this point. It's also >>>> immediately spitting out 'no' after printing 'checking if fixpath can be >>>> created...', even before all the output from the compiler, so it almost >>>> seems like the command is being fired off from somewhere else? Or maybe >>>> it's >>>> just a race condition, idk. >>>> >>> What version of OpenJDK are you trying to build? As in which >>> repository did you clone. Depending on which, you may need to >>> explicitly regenerate the configure script after making changes to .m4 >>> files. There is a script, autogen.sh, in the same directory as the .m4 >>> files to do it correctly. This requires autoconf 2.69 to be available. >>> >>> The language in .m4 is autoconf, which (in our case) is bash shell >>> with m4 macros on top. Most of the source, including your snippet >>> above is just bash. So your change above looks correct, you just need >>> to get it to be used. You could try changing the -x to -e in case >>> execute permissions aren't translated properly between msys and >>> windows. >>> >>> /Erik >>>> >>>> If you have any more suggestions I really appreciate it, but if it's too >>>> much trouble for an unsupported build system I understand. >>>> >>>> Best regards, >>>> Jorn Vernee >>>> >
