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

Tue Jun 12 13:56:23 UTC 2018

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