Boost C++ Libraries: Ticket #9301: Error when attempting to boot strap boost https://svn.boost.org/trac10/ticket/9301 <p> Error when attempting to bootstrap boost </p> <p> Hello, </p> <p> I am getting the following error when attempting to run "bootstrap.bat mingw." </p> <p> Building Boost.Build engine builtins.c: In function 'builtin_readlink': builtins.c:1879:39: error: 'FSCTL_GET_REPARSE_POINT' undeclared (first use in this function) </p> <blockquote> <p> int okay = <a class="missing wiki">DeviceIoControl</a>(hLink, FSCTL_GET_REPARSE_POINT, NULL, 0, &amp;buf, sizeof(buf), &amp;n, NULL); </p> <blockquote> <p> <sup> </sup></p> </blockquote> </blockquote> <p> builtins.c:1879:39: note: each undeclared identifier is reported only once for each function it appears in </p> <p> Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics. </p> <p> This error does not happen with MSVC but it does happen with MinGW. </p> <p> For both MinGW and MSVC, FSCTL_GET_REPARSE_POINT is defined in winioctl.h. However, this header file is not directly included in builtins.c. Only Windows.h is directly included in builtins.c. </p> <p> This compiles for MSVC because winioctl.h is included by winscard.h which is in turn included by Windows.h. But winscard.h does not even exist in the MinGW header files and the MinGW version of Windows.h does not include winioctl.h. Thus winioctl.h is not indirectly included as it is in MSVC. </p> <p> The solution is obvious. Do not assume that the header fill will be indirectly included as a side effect of including Windows.h. Instead modify builtins.c to directly include winioctl.h. With this one line change the error is resolved. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/9301 Trac 1.4.3 Steven Watanabe Thu, 03 Apr 2014 04:06:54 GMT <link>https://svn.boost.org/trac10/ticket/9301#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/9301#comment:1</guid> <description> <p> This is not a "side-effect." The inclusion of winioctl.h is part of the documented behavior of Windows.h. Including Windows.h is correct according to MSDN. <a class="ext-link" href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa364571%28v=vs.85%29.aspx"><span class="icon">​</span>http://msdn.microsoft.com/en-us/library/windows/desktop/aa364571%28v=vs.85%29.aspx</a> </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Ben Key</dc:creator> <pubDate>Thu, 03 Apr 2014 04:29:33 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/9301#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/9301#comment:2</guid> <description> <p> I think you misunderstand what I was saying. I was not saying that including Windows.h is wrong. I am saying that assuming that including Windows.h will automatically cause winioctl.h to be included on every compiler in existence is wrong. And referring to Microsoft documentation that is specific to Microsoft Visual Studio does not disprove my point. </p> <p> When Boost is compiled using MinGW there is a compilation error due to the use of a constant that is not defined by any of the directly included header files. You get away with not including the header file in which the constant is defined on one compiler, but Boost is a library that supports many compilers and many operating systems. </p> <p> On one very commonly used compiler including Windows.h does not cause winioctl.h to be included. The solution is simple, add one line of code to Boost. Do not say that "Microsoft says thus and we only care about compilers that do as Microsoft says." </p> <p> My suggested change is to include winioctl.h in addition to Windows.h since not all versions of Windows.h in existence cause winioctl.h to be included. </p> <p> I would understand your resistance to this change if I was referring to a compiler that no one uses, but MinGW is a heavily used version of GCC. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Steven Watanabe</dc:creator> <pubDate>Thu, 03 Apr 2014 15:09:45 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/9301#comment:3 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/9301#comment:3</guid> <description> <p> Note that this has been fixed in recent MinGW. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Steven Watanabe</dc:creator> <pubDate>Thu, 03 Apr 2014 15:17:22 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/9301#comment:4 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/9301#comment:4</guid> <description> <p> Never mind that. I was thinking of something else. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Steven Watanabe</dc:creator> <pubDate>Thu, 03 Apr 2014 16:12:37 GMT</pubDate> <title>status changed; resolution set https://svn.boost.org/trac10/ticket/9301#comment:5 https://svn.boost.org/trac10/ticket/9301#comment:5 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> Fixed in <a class="ext-link" href="http://github.com/boostorg/build/commit/702d40baf90246544b93982f2f46f670f5bd7f1d"><span class="icon">​</span>http://github.com/boostorg/build/commit/702d40baf90246544b93982f2f46f670f5bd7f1d</a>. </p> Ticket