bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe

Tue Jun 12 09:49:00 UTC 2018

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
>
> 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
>>>>
>