
On 7/2/2013 11:04 AM, Kirk Joppy wrote:
Open a the new commandline window, and type "bootstrap.bat mingw" in the boost souce root dir to build the b2.exe and bjam.exe.
Yes adding "mingw" to the bootrap.bat invocation seems to be the trick.
To summarize explicitly the differences between what the docs say and what works:
What the docs say to do:
add MinGW\bin to PATH (not actually in boost docs but reasonably obvious from MinGW install instructions) cd BOOST_ROOT\tools\build\v2 bootstrap.bat b2 install --prefix=<some build dir> add <some build dir>\bin to PATH cd BOOST\ROOT b2 --build-dir=<some build dir> toolset=gcc --build-type=complete stage
What works:
add MinGW\bin to PATH cd BOOST_ROOT bootstrap.bat mingw b2 toolset=gcc --prefix=<some build dir>
There is obviously a lot of confusion here. Will someone fix the documentation? Will someone explain why the docs say to do things in the more convoluted way?
regards, kjoppy _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
That doesn't work for me: (this is from the msys shell) $ ./bootstrap.sh mingw Building Boost.Build engine with toolset gcc... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details Other info: $ g++ -v Using built-in specs. COLLECT_GCC=C:\MinGW\bin\g++.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.2 (GCC) (hopefully that's not too mangled :-P) And the contents of bootstrap.log: ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathsys.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c class.c cwd.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order. c execunix.c fileunix.c builtins.c:34:23: fatal error: sys/wait.h: No such file or directory compilation terminated. execunix.c:20:26: fatal error: sys/resource.h: No such file or directory compilation terminated. fileunix.c:96:17: fatal error: ar.h: No such file or directory compilation terminated. It seems like specifying the gcc toolset to bootstrap also makes the build process use unix APIs which I don't have on windows. Luckily I also have msvc, so I've been building b2 using msvc, and from there specifying gcc when building the actual boost libraries. It would be nice if you could use the same toolchain for both. Andy