Building OpenJDK 8 on Windows 8.1 Pro -- problems with msvcr100.dll

[Rich P]

Hi Erik -- thanks for the tip.  The latest version of autoconf available with the MinGW installation tools was 2.68.  I tried installing 2.69 manually but couldn't get it working.  Rather than pursuing the build with MinGW,  I have installed Cygwin and am going to try this again.
 
Thanks!
Rich
 
> Date: Tue, 5 Nov 2013 17:48:18 +0100
> From: erik.joelsson at oracle.com
> To: tempbox17 at hotmail.com; magnus.ihse.bursie at oracle.com
> CC: build-dev at openjdk.java.net
> Subject: Re: Building OpenJDK 8 on Windows 8.1 Pro -- problems with msvcr100.dll
> 
> When modifying a .m4 file, you need to have autoconf (version 2.69) 
> installed to regenerate generated-configure.sh. When running configure, 
> we have a check that makes sure it has been properly regenerated.
> 
> /Erik
> 
> On 2013-11-05 17:37, Rich P wrote:
> > Magnus --
> >   
> > Thanks for your help!  My comments below...
> >   
> >> Date: Tue, 5 Nov 2013 10:31:18 +0100
> >> From: magnus.ihse.bursie at oracle.com
> >> To: tempbox17 at hotmail.com
> >> CC: build-dev at openjdk.java.net
> >> Subject: Re: Building OpenJDK 8 on Windows 8.1 Pro -- problems with msvcr100.dll
> >>
> >> On 2013-11-05 09:01, Magnus Ihse Bursie wrote:
> >>>> Using the setup below, the configure script fails with the following
> >>>> msvcr100.dll-related errors:
> >>>>    (1) configure: The file type of the located msvcr100.dll is PE32+
> >>>> executable for MS Windows (DLL) (GUI) Mono/.Net assembly
> >>> That's a new one. Where did configure pick this one up?
> >>>> MinGW/MSYS (mingw-developer-toolkit, mingw32-base & msys-base
> >>>> versions 2013072300, mingw32-gcc-g++ version 4.8.1-4)
> >>> Aha, you're using msys! The recommended build environment on Windows
> >>> is cygwin. I didn't think msys was actually working at this point.
> >>>
> >>> It might be the case that the msys "file" command classifies the dll
> >>> differently.
> >> That was indeed exactly the case. For the same, 64-bit file, file in
> >> Cygwin classifies it as:
> >> "PE32+ executable (DLL) (GUI) x86-64, for MS Windows"
> >> but file in msys classifies it as:
> >> "PE32+ executable for MS Windows (DLL) (GUI) Mono/.Net assembly"
> >>
> >> The latter is apparently wrong. :(  I ran "file msvcr100.dll" and got the same message as you.
> >   
> >> On Ubuntu 11.04, file says the same as msys; on Ubuntu 13.10 it says the
> >> same as cygwin.
> >> Both Ubuntu 11.04 are using file 5.04, both Ubuntu 13.10 and my cygwin
> >> are using file 5.11.
> >>
> >> So, msys is shipping an old and broken version of file.
> >>
> >> However, for our practical purposes, we can assume that PE32+ (in
> >> contrast to PE32) is enough to distinguish the bitness of the dll. (That
> >> is not enough, in theory, but will be for this specific case.)
> >>
> >> To get past this, try modifying
> >> CORRECT_MSVCR_ARCH=x86-64
> >> in toolchain_windows.m4 to
> >> CORRECT_MSVCR_ARCH=PE32+
> >> After updating toolchain_windows.m4 as you suggest above and re-running  "bash ./configure", the script stops with the message:
> > Configure source code has been updated, checking time stamps
> > Running generated-configure.sh I pulled a fresh copy of the sources and tried again and the script will not run after I modify toolchain_windows.m4.  Perhaps modifying the file (and thus the file's timestamp) is preventing the configure script from running.  Does the script check file timestamps?  If so, is there an easy way to get around this? Thx!Rich
> >> I'll file a bug to figure out a more proper solution.
> >>
> >> /Magnus
> >   		 	   		
>