RE: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Hi Magnus, Yes, I have signed OCA last October, and Dalibor Topic has processed it. I’m happy to work on the msys2 build part with you and Erik. As far as I recall, the hotspot tests were really close, the number of failed test cases seemed to be manageable: == Test summary == TEST TOTAL PASS FAIL ERROR >> jtreg:hotspot/test:hotspot_all 1428 13643331 << == Peter Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Magnus Ihse Bursie Sent: Friday, June 15, 2018 3:38:08 PM To: Peter Budai Cc: build-dev Subject: Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe 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 <mailto:thomas.stu...@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 <mailto:magnus.ihse.bur...@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 magnit
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
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 *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 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, thank
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Hey Erik, I was running into warnings in the standard library being treated as errors with VS 2015, so --disable-warnings-as-errors did the trick :D The information I remembered turned out to be outdated. I went and looked at doc/building.html again and found that amber required at least VS 2013 update 4. I should have RTFM (oops). The toolchain_windows.m4 tip was a good one, it looks like the repo also supports VS 2017, so I'm now building using the BuildTools version of 2017 successfully (thanks for the tip). Tbh, it feels really great to finally get this working :) The support for newer versions of VS is really appreciated. Thanks for all the help, Jorn Vernee Erik Joelsson schreef op 2018-06-12 15:56: Hello, Glad to hear you got Cygwin in order! The officially supported toolchain for jdk/jdk (current mainline for JDK 11) is VS 2017. We recently upgraded from 2013. Amber seems to be pretty much up to date with that from looking at the repo changes. You can check at the top of toolchain_windows.m4 for the list of VS versions. The order of that list shows our preference. I do not think 2010 works well since we upgraded from that to 2013 a long time ago in JDK 9. I do believe 2015 should work, but last I tried, I needed to add --disable-warnings-as-errors to get through. For 2017, you only need the "BuildTools" edition if you want to minimize the install. If you want the Visual Studio IDE, then community edition works just as well. If you are running Windows 10, you can also try installing the Windows Subsystem for Linux. In my experience, OpenJDK builds pretty much out of the box in Ubuntu under WSL as long as you provide a bootjdk of the correct version (for Linux). You get a Linux binary that works in WSL (or native Linux). /Erik
RE: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
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
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
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&q
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Hello, Glad to hear you got Cygwin in order! The officially supported toolchain for jdk/jdk (current mainline for JDK 11) is VS 2017. We recently upgraded from 2013. Amber seems to be pretty much up to date with that from looking at the repo changes. You can check at the top of toolchain_windows.m4 for the list of VS versions. The order of that list shows our preference. I do not think 2010 works well since we upgraded from that to 2013 a long time ago in JDK 9. I do believe 2015 should work, but last I tried, I needed to add --disable-warnings-as-errors to get through. For 2017, you only need the "BuildTools" edition if you want to minimize the install. If you want the Visual Studio IDE, then community edition works just as well. If you are running Windows 10, you can also try installing the Windows Subsystem for Linux. In my experience, OpenJDK builds pretty much out of the box in Ubuntu under WSL as long as you provide a bootjdk of the correct version (for Linux). You get a Linux binary that works in WSL (or native Linux). /Erik On 2018-06-12 05:40, jbvernee wrote: Hello guys, I tried the rebaseall and it worked. Tbh, I hadn't really looked into cygwin that much since I wanted to avoid having PATH conflicts between 3 different versions of tools (one windows, one msys, and one cygwin). I should have done that right away though since it was really easy to get working, and also runs 'configure' about 10x faster (although having to use the installer to install packages is somewhat annoying). I think I'll just shelf msys2 for now, since it's not that important to me, and building openjdk is more of a hobby thing any ways. Btw, the patch that you linked, Magnus, is private, i.e. it returns a '403 - Forbidden'. I have thought about using virtualbox to emulate linux to build in there, but it requires me to enable virtualization in my BIOS and doing that makes my machine boot up significantly slower. Fast startup is more important to me (like I said, building ojdk is more of a hobby thing). I also have a decade old PC that runs Ubuntu, but I'm sharing the monitor with someone else, so I can't always use it. That's why I've settled on getting the build to work natively. Any ways, I ran configure and ended up with the following (I'm trying to build the amber repo btw): ``` The existing configuration has been successfully updated in /cygdrive/j/cygwin64/home/Jorn/cygwin-projects/amber/build/windows-x86_64-normal-server-release using default settings. Configuration summary: * Debug level: release * HS debug level: product * JVM variants: server * JVM features: server: 'aot cds cmsgc compiler1 compiler2 g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services vm-structs' * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 * Version string: 11-internal+0-adhoc.Jorn.amber (11-internal) Tools summary: * Environment: cygwin version 2.10.0(0.325/5/3) (root at /cygdrive/j/cygwin64) * Boot JDK: java version "10.0.1" 2018-04-17 Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode) (at /cygdrive/c/progra~1/java/jdk-10) * Toolchain: microsoft (Microsoft Visual Studio 2012) * C Compiler: Version 17.00.61030 (at /cygdrive/j/progra~2/micros~3.0/vc/bin/x86_am~1/cl) * C++ Compiler: Version 17.00.61030 (at /cygdrive/j/progra~2/micros~3.0/vc/bin/x86_am~1/cl) Build performance summary: * Cores to use: 7 * Memory limit: 8124 MB WARNING: The result of this configuration has overridden an older configuration. You *should* run 'make clean' to make sure you get a proper build. Failure to do so might result in strange build problems. ``` I tried with VS 2015 community, but it was warning about not being supported? I guess that change hasn't propagated to the amber repo yet, so I'm using VS 2012 express. (I have also tried installing VS 2010 express, which I believe is recommended, but it doesn't seem to include a compiler? There's a service pack which I think includes the compiler, but it requires windows SDK 7.1 which 'encountered some problems during installation' *sigh*). Then running `make clean images` I had an error about inttypes.h missing, which I downloaded to fix that error, but now it's also complaining about other stuff like: ``` j:\cygwin64\home\Jorn\cygwin-projects\amber\test\fmw\gtest\include\gtest/gtest-printers.h(550) : error C2977: 'std::tuple' : too many template arguments j:\progra~2\micros~3.0\vc\include\utility(73) : see declaration of 'std::tuple' ``` And many more such errors after that. So I suppose VS 2012 express isn't supported either (even though it doesn't give a warning)? Maybe I'm missing something, I only installed VS 2012 express from here: https://www.visualstudio.com/vs/older-downloads/ . Or does the amber repo
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
Hello guys, I tried the rebaseall and it worked. Tbh, I hadn't really looked into cygwin that much since I wanted to avoid having PATH conflicts between 3 different versions of tools (one windows, one msys, and one cygwin). I should have done that right away though since it was really easy to get working, and also runs 'configure' about 10x faster (although having to use the installer to install packages is somewhat annoying). I think I'll just shelf msys2 for now, since it's not that important to me, and building openjdk is more of a hobby thing any ways. Btw, the patch that you linked, Magnus, is private, i.e. it returns a '403 - Forbidden'. I have thought about using virtualbox to emulate linux to build in there, but it requires me to enable virtualization in my BIOS and doing that makes my machine boot up significantly slower. Fast startup is more important to me (like I said, building ojdk is more of a hobby thing). I also have a decade old PC that runs Ubuntu, but I'm sharing the monitor with someone else, so I can't always use it. That's why I've settled on getting the build to work natively. Any ways, I ran configure and ended up with the following (I'm trying to build the amber repo btw): ``` The existing configuration has been successfully updated in /cygdrive/j/cygwin64/home/Jorn/cygwin-projects/amber/build/windows-x86_64-normal-server-release using default settings. Configuration summary: * Debug level:release * HS debug level: product * JVM variants: server * JVM features: server: 'aot cds cmsgc compiler1 compiler2 g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services vm-structs' * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 * Version string: 11-internal+0-adhoc.Jorn.amber (11-internal) Tools summary: * Environment:cygwin version 2.10.0(0.325/5/3) (root at /cygdrive/j/cygwin64) * Boot JDK: java version "10.0.1" 2018-04-17 Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode) (at /cygdrive/c/progra~1/java/jdk-10) * Toolchain: microsoft (Microsoft Visual Studio 2012) * C Compiler: Version 17.00.61030 (at /cygdrive/j/progra~2/micros~3.0/vc/bin/x86_am~1/cl) * C++ Compiler: Version 17.00.61030 (at /cygdrive/j/progra~2/micros~3.0/vc/bin/x86_am~1/cl) Build performance summary: * Cores to use: 7 * Memory limit: 8124 MB WARNING: The result of this configuration has overridden an older configuration. You *should* run 'make clean' to make sure you get a proper build. Failure to do so might result in strange build problems. ``` I tried with VS 2015 community, but it was warning about not being supported? I guess that change hasn't propagated to the amber repo yet, so I'm using VS 2012 express. (I have also tried installing VS 2010 express, which I believe is recommended, but it doesn't seem to include a compiler? There's a service pack which I think includes the compiler, but it requires windows SDK 7.1 which 'encountered some problems during installation' *sigh*). Then running `make clean images` I had an error about inttypes.h missing, which I downloaded to fix that error, but now it's also complaining about other stuff like: ``` j:\cygwin64\home\Jorn\cygwin-projects\amber\test\fmw\gtest\include\gtest/gtest-printers.h(550) : error C2977: 'std::tuple' : too many template arguments j:\progra~2\micros~3.0\vc\include\utility(73) : see declaration of 'std::tuple' ``` And many more such errors after that. So I suppose VS 2012 express isn't supported either (even though it doesn't give a warning)? Maybe I'm missing something, I only installed VS 2012 express from here: https://www.visualstudio.com/vs/older-downloads/ . Or does the amber repo require some tricks to get working? Close yet so far. Thanks, Jorn Vernee Thomas Stüfe schreef op 2018-06-12 11:49: 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 wrote: Hi
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
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
>>
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
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 =
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
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
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
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
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
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? 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. 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`
Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
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
bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe
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
