Windows: problem with msvxxx.dll locations containing spaces

Erik Joelsson erik.joelsson at oracle.com
Thu May 3 20:13:06 UTC 2018


Hello,

In my case, VCINSTALLDIR is in short form already. Could you try 
changing line 543 from BASIC_WINDOWS_REWRITE_AS_UNIX_PATH to 
BASIC_FIXUP_PATH?

/Erik


On 2018-05-03 11:17, Thomas Stüfe wrote:
> Hi Erik,
>
> I see the error on two very different machines. One is my private
> machine - windows 7, VS2013 and VS2017 installed. The second one is my
> corporate Laptop, Windows 10 and only VS2013.
>
> In both cases I use a very recent cygwin64 installation.
>
> Both cases run in TOOLCHAIN_SETUP_MSVC_DLL into the "# Probe: Using
> well-known location from Visual Studio 12.0 and older" case, and in
> the for loop at line 559 attempt to tokenize the POSSIBLE_MSVC_DLL
> variable content. Here the 64bit build on my corporate laptop:
>
> checking if fixpath.exe works... yes
> POSSIBLE_MSVC_DLL /cygdrive/c/Program
> POSSIBLE_MSVC_DLL Files
> POSSIBLE_MSVC_DLL (x86)/Microsoft
> POSSIBLE_MSVC_DLL Visual
> POSSIBLE_MSVC_DLL Studio
> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll
> configure: Found msvcr120.dll at
> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in
> SYSTEMROOT
> checking found msvcr120.dll architecture... ok
> checking for msvcr120.dll... /cygdrive/c/WINDOWS/system32/msvcr120.dll
> POSSIBLE_MSVC_DLL /cygdrive/c/Program
> POSSIBLE_MSVC_DLL Files
> POSSIBLE_MSVC_DLL (x86)/Microsoft
> POSSIBLE_MSVC_DLL Visual
> POSSIBLE_MSVC_DLL Studio
> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcp120.dll
> configure: Found msvcp120.dll at
> /cygdrive/c/WINDOWS/system32/msvcp120.dll using well-known location in
> SYSTEMROOT
>
> As you can see, we fall back to the default in windows/system32, which
> happens to be working for 64bit. On 32bit, we get this error:
>
> checking if fixpath.exe works... yes
> POSSIBLE_MSVC_DLL /cygdrive/c/Program
> POSSIBLE_MSVC_DLL Files
> POSSIBLE_MSVC_DLL (x86)/Microsoft
> POSSIBLE_MSVC_DLL Visual
> POSSIBLE_MSVC_DLL Studio
> POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll
> configure: Found msvcr120.dll at
> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in
> SYSTEMROOT
> checking found msvcr120.dll architecture... incorrect, ignoring
> configure: The file type of the located msvcr120.dll is PE32+
> executable (DLL) (GUI) x86-64, for MS Windows
> configure: Found msvcr120.dll at /cygdrive/c/Program Files
> (x86)/Microsoft Visual Studio
> 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using search of
> VCINSTALLDIR
> checking found msvcr120.dll architecture... incorrect, ignoring
> configure: The file type of the located msvcr120.dll is PE32
> executable (DLL) (GUI) ARMv7 Thumb, for MS Windows
> checking for msvcr120.dll... no
> configure: error: Could not find msvcr120.dll. Please specify using
> --with-msvcr-dll.
> configure exiting with result code 1
>
> Best Regards, Thomas
>
> On Thu, May 3, 2018 at 7:18 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Also, on my windows system, if I try using my local Visual Studio, both MSVC
>> dll's are found in the Visual Studio dir, and the spaces are all cleaned up.
>> I wonder what's different about your setup, Thomas.
>>
>> /Erik
>>
>>
>>
>> On 2018-05-03 10:13, Erik Joelsson wrote:
>>> Hello,
>>>
>>> On 2018-05-03 03:41, Magnus Ihse Bursie wrote:
>>>> I think the main issue here is that BASIC_FIXUP_PATH should be called for
>>>> the located msvcr*.dll files. I don't have time to look at it now, but see
>>>> if you can do a rewrite using BASIC_FIXUP_PATH when the potential file is
>>>> located. This should remove all spaces from the path.
>>>>
>>> No, that is not a good solution. I intentionally removed that
>>> BASIC_FIXUP_PATH because in VS2017, one of the files has a file name longer
>>> than 8 characters and BASIC_FIXUP_PATH rewrites that filename to short
>>> style. This in turn has weird consequences in make when we copy that file
>>> using generated copy rules. The target file then gets the short style name
>>> literally.
>>>
>>> When I made that change, I looked at all the calls for potential locations
>>> and thought all of them had the directory prepared properly already. It
>>> seems I was wrong. I think the correct solution is to either get rid of
>>> spaces earlier for all the input directories we search, or maybe tweak
>>> BASIC_FIXUP_PATH to not touch the actual filename.
>>>
>>> /Erik
>>>> /Magnus
>>>>
>>>> On 2018-05-02 20:46, Thomas Stüfe wrote:
>>>>> Hi,
>>>>>
>>>>> My 32bit builds on Windows were failing since quite a while and I
>>>>> finally had some minutes to look into that.
>>>>>
>>>>> See prior discussion here:
>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html
>>>>>
>>>>> My output used to look like this:
>>>>>
>>>>> checking if fixpath.exe works... yes
>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program
>>>>> POSSIBLE_MSVC_DLL Files
>>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft
>>>>> POSSIBLE_MSVC_DLL Visual
>>>>> POSSIBLE_MSVC_DLL Studio
>>>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll
>>>>> configure: Found msvcr120.dll at
>>>>> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in
>>>>> SYSTEMROOT
>>>>>
>>>>> So basically, build does not correctly search for msvcr120.dll in
>>>>> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio
>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it
>>>>> fails and falls back to the system default
>>>>> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll,
>>>>> and so configure fails.
>>>>>
>>>>> Note that 64bit build shows exactly the same behaviour! Only there it
>>>>> works by accident, since the default
>>>>> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a
>>>>> 64bit library too, so configure succeeds.
>>>>>
>>>>> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in
>>>>> toolchain_windows.m4. We use a bash for loop to iterate thru a list of
>>>>> one or more files, but that for expression should be quoted.
>>>>>
>>>>> If I make this fix:
>>>>>
>>>>> --- a/make/autoconf/toolchain_windows.m4        Mon Apr 23 18:04:17 2018
>>>>> -0700
>>>>> +++ b/make/autoconf/toolchain_windows.m4        Wed May 02 18:38:04 2018
>>>>> +0200
>>>>> @@ -556,7 +556,7 @@
>>>>>            fi
>>>>>          fi
>>>>>          # In case any of the above finds more than one file, loop over
>>>>> them.
>>>>> -      for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do
>>>>> +      for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do
>>>>>            $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll"
>>>>>            TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME],
>>>>> [$possible_msvc_dll],
>>>>>                [well-known location in VCINSTALLDIR])
>>>>>
>>>>>
>>>>> the 32bit configure correctly sets the msvcrt dll:
>>>>>
>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual
>>>>> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll
>>>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files
>>>>> (x86)/Microsoft Visual Studio
>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known
>>>>> location in VCINSTALLDIR
>>>>> checking found msvcr120.dll architecture... ok
>>>>>
>>>>> and I can start the build, but I get follow up errors:
>>>>>
>>>>> ...
>>>>> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s)
>>>>> Compiling 2 files for BUILD_JVMTI_TOOLS
>>>>> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by
>>>>>
>>>>> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'.
>>>>> Stop.
>>>>> make[3]: *** Waiting for unfinished jobs....
>>>>> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2
>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>>
>>>>> I stopped looking at that point, but to me it looks like the build
>>>>> cannot survive msvcrt.dll locations with spaces in them.
>>>>>
>>>>> Kind Regards, Thomas
>>>>




More information about the build-dev mailing list