bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Peter Budai
peterbudai at hotmail.com
Fri Jun 15 15:39:44 UTC 2018
Hi Magnus,
Yes, I have signed OCA last October, and Dalibor Topic has processed it.
I’m happy to work on the msys2 build part with you and Erik.
As far as I recall, the hotspot tests were really close, the number of failed test cases seemed to be manageable:
==============================
Test summary
==============================
TEST TOTAL PASS FAIL ERROR
>> jtreg:hotspot/test:hotspot_all 1428 1364 33 31 <<
==============================
Peter
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
________________________________
From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Friday, June 15, 2018 3:38:08 PM
To: Peter Budai
Cc: build-dev
Subject: Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
On 2018-06-12 17:26, Peter Budai wrote:
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.
Hi Peter,
I think you should split up your work in two parts. The first would be to just build OpenJDK on msys2. Since we have been supporting msys in the past, this should be trivial to just get pushed.
The next step would probably involve me (or possibly Erik) cleaning up some of the logic in the shared build code, were we have incorrectly tested if the OS is Windows, when we *really* should have tested if we've using the Microsoft toolchain. It's been on my mental todo list for quite some time, but since we have up until now had a 1-1 relationship between OS and toolchain, this has not been prioritized.
With that in place, your patches can probably be easily adapted. Then comes the hard part of figuring out what is causing the failures (if you're lucky it's all the symptoms of a very short list of real issues, most likely incorrectly compiled code in Hotspot).
We have traditionally have had quite a high bar for allow new ports, but a much lower bar for accepting a new compiler for an existing platform, so I assume that you will not get as much resistance from that point.
Have you signed the OCA (Oracle Contributor's Agreement)? [1] That's a prerequisite for any patches to be accepted.
/Magnus
[1] http://openjdk.java.net/contribute/
Good luck on your journey.
Peter
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
________________________________
From: Thomas Stüfe <thomas.stuefe at gmail.com><mailto:thomas.stuefe at 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.bursie at oracle.com><mailto:magnus.ihse.bursie at 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<http://cr.openjdk.java.net/%7Eihse/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
>>>>
>
More information about the build-dev
mailing list