Bug 99055 - Configure failure with Windows 10 SDK
Summary: Configure failure with Windows 10 SDK
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-03 02:14 UTC by William Kent
Modified: 2016-12-19 03:01 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
Autoconf log file from when the error occurred (103.60 KB, text/plain)
2016-04-03 02:14 UTC, William Kent
Details

Note You need to log in before you can comment on or make changes to this bug.
Description William Kent 2016-04-03 02:14:38 UTC
Created attachment 124035 [details]
Autoconf log file from when the error occurred

When I try to run autogen.sh as recommended on https://wiki.documentfoundation.org/Development/BuildingOnWindows the configure step fails complaining that it can't determine the C++ standard library. I am using the Windows SDK 10.0.14295.0, with versions 10.0.10240.0 and 10.0.10586.0 also installed. The root cause of this issue is thus:

1. The <utility> header includes a file called "corecrt.h"
2. This file is looked for in the -I paths, which are:
      C:/PROGRA~2/WIN3CF2~1/10/Include/10.0.14295/ucrt
3. The above path is *not correct*, it does not (and should not, as it has
   incorrect Microsoft version-number syntax) exist. The correct path is:
      C:/PROGRA~2/WIN3CF2~1/10/Include/10.0.14295.0/ucrt
   Note the added ".0" in the version number.
4. Corecrt.h is not found, and the build fails as it cannot successfully
   identify the Visual Studio C++ library.

This appears to be a bug in how Autoconf generates the configure script. As far as I can see, it is using the cygpath program to normalize all paths to their 8.3 equivalents. This is for whatever reason removing the last ".0" in the version number. I do not know how to correct this on my end, or workaround it (I have tried adding a symlink with the name the configure script uses, to no avail).

The full config.log file is attached.
Comment 1 William Kent 2016-04-03 03:12:10 UTC
I found that this was due to a misconfiguration on my system (the Registry ProductVersion Registry value lacked the trailing ".0" that was causing the problem). A manual fix using regedit solved the problem.
Comment 2 steve 2016-04-03 08:59:26 UTC
So not fixed but notabug. thx for the update.
Comment 3 Regis Perdreau 2016-12-19 03:01:08 UTC
I confirm the isssue. 

Path from autogen script is :

(output of autogen)
checking for explicit CFLAGS...  -IC:/PROGRA~2/WI3CF2~1/10/Include/10.0.14393/ucrt
checking for explicit CXXFLAGS...  -IC:/PROGRA~2/WI3CF2~1/10/Include/10.0.14393/ucrt


but real path is :

C:/PROGRA~2/WI3CF2~1/10/Include/10.0.143930.0/ucrt