Re: [boost] [build] bootstrap.sh is still broken

Subject: Re: [boost] [build] bootstrap.sh is still broken
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2013-10-28 22:47:04

[niXman]
> The same error.

Thanks. I don't know why bootstrap.bat is exploding for you, but that
exonerates my changes.

Eric - this should unblock you from merging checkin 86460 to release.

[Eric Niebler]
> builtins.c:1879:39: error: 'FSCTL_GET_REPARSE_POINT' undeclared (first use
in this function)
> So it looks like something is still broken. Stephan?

This is a separate problem which must have appeared after 1.54.0, otherwise
I would have complained about it.

[Steven Watanabe]
> The problem is that MinGW's windows.h is only a
> subset of the real windows.h.  This is part
> of the code used to handle symlinks for the
> git transition.  I didn't test it on mingw.

If you can fix this for 1.55.0's release, that would be wonderful. A fix in
trunk would be almost as good, since I could backport it. Otherwise, I'll
have to figure out how to hack around this myself.

By the way, mingw-w64's maintainers are very responsive - if you need more
stuff from their headers, I'm sure they'll happily provide it.

[Eric Niebler]
> Why use the posix emulator? Why use mingw at all? I confess to be
> totally n00b about this stuff, but if you want to build boost using gcc
> on windows, it would seem to make sense to me to install mingw and then
> do things The Mingw Way, no?

Both bootstrap.bat and bootstrap.sh are valid approaches. Years ago, I used
to use the .bat, but I switched to the .sh because I have to build
everything else in MSYS.

> 1) There is a bootstrap.bat both at $BOOST_ROOT and and
> $BOOST_ROOT/tools/build/v2. They are different. Are we all taking about
> the same one? Which one should I be using (and why do we have two)?

I am familiar with the .bat in the root. I don't know what the other one is
doing.

> 2) Stephan's mingw distribution doesn't include gcc. I'm wondering how
> he expects things to work.

Why do you say that? Of course I have it.

C:\Temp>where gcc
C:\MinGW\bin\gcc.exe

C:\Temp>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto
-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../src/configure --enable-languages=c,c++
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-multilib --prefix=/c/temp/gcc/dest
--with-sysroot=/c/temp/gcc/dest --disable-libstdcxx-pch --disable-lto
--disable-nls --disable-shared --disable-win32-registry
--enable-checking=release --with-tune=core-avx-i
Thread model: win32
gcc version 4.8.1 (GCC)

As my page explains, my distro does not modify your system, so gcc.exe will
not automatically appear in your Command Prompt's path. You must either run
set_distro_paths.bat to put the distro on *that* Command Prompt's path (it
will not affect other/future instances), or double-click
open_distro_window.bat to open a new Command Prompt with the distro on its
path.

If you've mangled your installation (*), simply delete the directory and run
the self-extracting archive again. This is why I love zips and hate
installers.

STL
* I once received a bug report from a user who claimed that
C:\MinGW\x86_64-w64-mingw32\include\sys wasn't in the right place. He had
accidentally drag-moved it in Windows Explorer.