bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Tue Jun 12 06:53:15 UTC 2018
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
>>>
More information about the build-dev
mailing list