bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Fri Jun 15 13:38:08 UTC 2018
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>
> *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> 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