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

[Erik Joelsson]

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
>
> Erik Joelsson schreef op 2018-06-11 19:51:
>> Hello Jorn,
>>
>> I don't have access to an msys2 environment to try this myself and as
>> we don't regularly build there, it's unfortunately not expected to
>> work. Msys has a habit of trying to outsmart the user when treating
>> paths, by automatically converting path formats from unix style to
>> windows style by trying to detect what kind of process is receiving
>> it. In my experience, this automatic behavior trips you up more often
>> than it helps you and it looks like that is what's happening here.
>>
>> The tool fixpath.exe is our internal solution to the path troubles. We
>> build it in configure and then use it to convert paths to windows
>> style for any process that we know need it. Unfortunately for you,
>> your setup is failing before managing to create the tool itself.
>>
>> I would try to supply the value for the variable in Unix style
>> (/j/msys/...) and see if msys converts it correctly then.
>>
>> /Erik
>>
>>
>> On 2018-06-11 07:38, jbvernee wrote:
>>> Hello,
>>>
>>> I've been trying to build the JDK using an msys2 toolchain, which 
>>> seems to be possible according to this thread: 
>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019862.html 
>>> (although I'm not trying to use gcc, I'm using VS 15). I know it's 
>>> advised to use cygwin, but I can't get that to work at all on my 
>>> machine (some error about base heap offset after a fresh install. I 
>>> might try troubleshooting that next...)
>>>
>>> I'm running into the error mentioned in the subject line while 
>>> running `bash configure`, namely:
>>>
>>>     LINK : fatal error LNK1104: cannot open file 
>>> 'J:J:/msys64/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
>>>
>>> I have also created a gist of the full configure log: 
>>> https://gist.github.com/JornVernee/6b579e6d13d1fce306d0d370a381d1b3
>>>
>>> Looking at this, it seems like the path is getting mangled. The 
>>> correct path is 
>>> 'J:/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe' 
>>> But as you can see there is an extra `J:/msys64` in there, which 
>>> happens to be the root of my msys2 installation (though I'm running 
>>> configure in PowerShell, and not in the included msys2 environment. 
>>> Switching between them doesn't fix the problem either though).
>>>
>>> I thought I had traced the value of this path to the `OUTPUTDIR` 
>>> variable in `\make\autoconf\basics.m4`, where it is created inside 
>>> this if-else block:
>>>
>>> ```
>>>     if test "x$CUSTOM_ROOT" != x; then
>>>       OUTPUTDIR="${CUSTOM_ROOT}/build/${CONF_NAME}"
>>>     else
>>>       OUTPUTDIR="${TOPDIR}/build/${CONF_NAME}"
>>>     fi
>>> ```
>>>
>>> Where it is then used to create the `CONFIGURESUPPORT_OUTPUTDIR` 
>>> path like: 
>>> `CONFIGURESUPPORT_OUTPUTDIR="$OUTPUTDIR/configure-support"`, and 
>>> finally the output path for fixpath.exe is constructed from that in 
>>> `\make\autoconf\basics_windows.m4`:
>>>
>>> ```
>>>     FIXPATH_BIN="$CONFIGURESUPPORT_OUTPUTDIR/bin/fixpath.exe"
>>>     FIXPATH_DIR="$CONFIGURESUPPORT_OUTPUTDIR/fixpath"
>>> ```
>>>
>>> I have tried setting the `CUSTOM_ROOT` variable, but the error 
>>> remained the same. As a sanity check I rewrote the if-statement to: 
>>> `OUTPUTDIR="J:/Projects/openjdk/amber/build/${CONF_NAME}", but the 
>>> error message still remains the same.
>>>
>>> I have also tried manually compiling fixpath.c into fixpath.exe and 
>>> placing that file into 
>>> `/build/windows-x86_64-normal-server-release/configure-support/bin/`, 
>>> but the file is just ignored by the configuration script.
>>>
>>> At this point I don't know what else I could try. So I'm wondering 
>>> if anyone here has any suggestions?
>>>
>>> Best regards,
>>> Jorn Vernee