bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe (original) (raw)

Peter Budai peterbudai at hotmail.com
Tue Jun 12 15:26:58 UTC 2018

Previous message (by thread): bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Next message (by thread): bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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.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 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 MSYS2ARGCONVEXCL= (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 MSYS2ARGCONVEXCL 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 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>F</mi><mi>I</mi><mi>X</mi><mi>P</mi><mi>A</mi><mi>T</mi><mi>H</mi><mi>B</mi><mi>I</mi><mi>N</mi></mrow><annotation encoding="application/x-tex">FIXPATHBIN </annotation></semantics></math>FIXPATHBINFIXPATHDIR_ _#$MKDIR -p <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>F</mi><mi>I</mi><mi>X</mi><mi>P</mi><mi>A</mi><mi>T</mi><mi>H</mi><mi>D</mi><mi>I</mi><mi>R</mi></mrow><annotation encoding="application/x-tex">FIXPATHDIR </annotation></semantics></math>FIXPATHDIRCONFIGURESUPPORTOUTPUTDIR/bin_ _cd $CURDIR_ _echo "#####################" here_ _#if test ! -x $FIXPATHBIN; then_ _# cd $FIXPATHDIR_ _# <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>C</mi><mi>C</mi></mrow><annotation encoding="application/x-tex">CC </annotation></semantics></math>CCFIXPATHSRCW -Fe$FIXPATHBINW > $FIXPATHDIR/fixpath1.log_ _2>&1_ _# cd $CURDIR_ _#fi_ _echo "#####################" there_ _if test ! -x $FIXPATHBIN; then_ _{ <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>a</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>h</mi><mi>o</mi><mi mathvariant="normal">"</mi></mrow><annotation encoding="application/x-tex">asecho "</annotation></semantics></math>asecho"asme:${aslineno-$LINENO}: result: no" >&5_ _$asecho "no" >&6; }_ _cat $FIXPATHDIR/fixpath1.log_ _asfnerror <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo stretchy="false">?</mo><mi mathvariant="normal">"</mi><mi>C</mi><mi>o</mi><mi>u</mi><mi>l</mi><mi>d</mi><mi>n</mi><mi>o</mi><mi>t</mi><mi>c</mi><mi>r</mi><mi>e</mi><mi>a</mi><mi>t</mi><mi>e</mi></mrow><annotation encoding="application/x-tex">? "Could not create </annotation></semantics></math>?"CouldnotcreateFIXPATHBIN" "$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-x8664-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-x8664-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-x8664-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 basicswindows.m4 (line 406) to compile fixpath.exe: _ _cd $FIXPATHDIR_ _$CC <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>F</mi><mi>I</mi><mi>X</mi><mi>P</mi><mi>A</mi><mi>T</mi><mi>H</mi><mi>S</mi><mi>R</mi><mi>C</mi><mi>W</mi><mo>−</mo><mi>F</mi><mi>e</mi></mrow><annotation encoding="application/x-tex">FIXPATHSRCW -Fe</annotation></semantics></math>FIXPATHSRCW−FeFIXPATHBINW > $FIXPATHDIR/fixpath1.log_ _2>&1_ _cd $CURDIR_ _ They are: $CC = /j/progra~~2/micros~~2.0/vc/bin/amd64/cl $FIXPATHBINW = J:/Projects/openjdk/amber/make/autoconf/build/windows-x8664-normal-server-release/configure-support/bin/fixpath.exe $FIXPATHDIR = /J/Projects/openjdk/amber/make/autoconf/build/windows-x8664-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-x8664-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 MSYS2ARGCONVEXCL 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 basicswindows.m4 at line 404: _ _#$RM -rf <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>F</mi><mi>I</mi><mi>X</mi><mi>P</mi><mi>A</mi><mi>T</mi><mi>H</mi><mi>B</mi><mi>I</mi><mi>N</mi></mrow><annotation encoding="application/x-tex">FIXPATHBIN </annotation></semantics></math>FIXPATHBINFIXPATHDIR_ _#$MKDIR -p <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>F</mi><mi>I</mi><mi>X</mi><mi>P</mi><mi>A</mi><mi>T</mi><mi>H</mi><mi>D</mi><mi>I</mi><mi>R</mi></mrow><annotation encoding="application/x-tex">FIXPATHDIR </annotation></semantics></math>FIXPATHDIRCONFIGURESUPPORTOUTPUTDIR/bin_ _cd $CURDIR_ _if test ! -x $FIXPATHBIN; then_ _cd $FIXPATHDIR_ _$CC <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>F</mi><mi>I</mi><mi>X</mi><mi>P</mi><mi>A</mi><mi>T</mi><mi>H</mi><mi>S</mi><mi>R</mi><mi>C</mi><mi>W</mi><mo>−</mo><mi>F</mi><mi>e</mi></mrow><annotation encoding="application/x-tex">FIXPATHSRCW -Fe</annotation></semantics></math>FIXPATHSRCW−FeFIXPATHBINW > $FIXPATHDIR/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

Previous message (by thread): bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Next message (by thread): bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the build-dev mailing list