On 7/2/2013 1:18 PM, Kirk Joppy wrote:

...

Just to add, some additional steps apply for MinGW-w64 if you go in that direction in future

http://stackoverflow.com/questions/6100097/compiling-boost-with-mingw-w64

Craig, thanks for the useful information.

Does anyone else thing it's bad that we're trading StackOverflow links instead of fixing the documentation for the project? I'm just a newcomer but this seems really really bad to me. I don't see a way to edit the docs myself...

Perhaps posting to the boost build list would get the attention of someone who could address this issue. Jeff

On 7/2/2013 2:50 PM, Kirk Joppy wrote:

...

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

I am NOT an expert but my posted instructions are to be executed from the cmd.exe shell, not msys. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Ah, I missed that. Yes, from a cmd.exe prompt, bootstrap.bat does work. It is unexpected to have to leave the usual mingw development shell to be able to build boost (b2 specifically) with mingw! There is some mingw code in bootstrap.sh, which switches the toolset back to "gcc" for some reason. There is also some mingw handling in tools/build/v2/engine/build.sh, so I tried hacking bootstrap.sh to pass "mingw" onto build.sh rather than resetting it to gcc, but got the error reported earlier by 'Josu Andrade Gomes '. So there seems to be some attempt to make it work via the shell script, but perhaps it's still a work in progress? Anyway, as long as it works in *some* way! Thanks Andy

On 3 July 2013 02:04, Kirk Joppy wrote:

...

Anyway, as long as it works in *some* way!

I kind of think that's not the best approach. The build for this reasonably common use case is incorrectly documented in the official boost webpages. I think this really needs to get fixed. Note that I'm talking about boost webpages, not boost.build webpages. Anyone?

The source for the getting started guide is in 'more/getting_started' in your copy of boost. If editing the restructured text source code is too difficult, I can try to translate changes to the html (no promises, I don't really know restructured text myself). FWIW I don't know much about building on windows, let alone with mingw, so I can't help much here.

On 3 July 2013 08:53, Paul A. Bristow wrote:

Documentation for 'getting Boost going' has not been revised for years.

It doesn't mention MinGW very helpfully, as you found out, and makes no mention of Ubuntu, CodeBlocks, NetBeans, Eclipse ...

However, I think it is too late now - GIT is about to overwhelm us.

But new Modular GIT documentation must do better - this time we must keep refining the instructions to help the many newbies on a wider variety of platforms.

I'd favour using a Wiki process so users from the many platforms can contribute - (under GIT so changes that are disputed can be rolled back).

You don't need to wait for the git transition to start on something like this. I could setup the documentation build to pull documentation from an external repo.

I have got most of the 1.53 libraries built with MinGW, though some of them do not work correctly till now. I would like to share with you the following steps I did.

1. Add the bin folder of MinGW to your windows environment variable "PATH". 2. 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. 3. Type "b2 toolset=gcc --prefix=G:\boost_1_53_0\my-build' to build the libraries.

Zhiyu Li, Doing these steps works to produce libs and header files. However, when using MinGW and msys, it's nice to have the libs installed in such a way that usual Linux build tools like configure can actually find them. How did you deal with this? Did you just put the files in \MinGW\lib and \MinGW\include\boost? Also, I have posted on your wiki asking a similar question so if you like we can just bring the conversation there. -kjoppy

Hello people on our list, I added my answer to my github wiki. And let me post it here also. It's simply as shown below. I found this method from stackoverfow : http://stackoverflow.com/questions/13256788/building-boost-1-52-with-mingw C:\boost_1_54_0> bootstrap.bat mingw Building Boost.Build engine ... C:\boost_1_54_0> bjam toolset=gcc ---------------------------------------- Journeyer J. Joh o o s a p r o g r a m m e r a t g m a i l d o t c o m ---------------------------------------- 2013/7/5 Kirk Joppy

...

Also, I have posted on your wiki asking a similar question so if you like we can just bring the conversation there.

Ack, sorry, I confused you with another poster who had posted links to example code using boost with MinGW. He also posted a link to a Q/A wiki. Here are the links.

https://github.com/Journeyer/wxboost https://github.com/Journeyer/wxboost/wiki/QnA _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hi Kirk Joppy, I didn't use pkg-config. I didn't copy any header or library files of boost. I specified those paths on the IDE, code::blocks. As you might know my process is documented on my wiki. https://github.com/Journeyer/wxboost/wiki/QnA I believe using code::blocks is not a recommended way. I also wanted to know how I can make compiler automatically find the paths of header files and libraries using pkg-config on Windows and even Linux also. Thanks Journeyer ---------------------------------------- Journeyer J. Joh o o s a p r o g r a m m e r a t g m a i l d o t c o m ---------------------------------------- 2013/7/5 Kirk Joppy

...

C:\boost_1_54_0> bootstrap.bat mingw Building Boost.Build engine ... C:\boost_1_54_0> bjam toolset=gcc

I have a specific question about this:

When you do as you've written, I believe this makes compiled library files in boost_root\stage. In order to use MinGW you must then copy these files to \MinGW\lib, and also copy the headers to a directory called \MinGW\include\boost (since boost headers are supposed to be included as #include "boost\boost_lib". Is this what you did? This method of copying files bypasses pkg-config and the entire autotools utility system, so how do you manage your build system? Do you simply pass flags to your build system to ensure the libs are found? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

I haven't used autotools in mingw/msys environment but I think you can specify those paths with autotools also. Makefile.am is for those purpose in my case. bin_PROGRAMS = logging_client logging_client_CPPFLAGS = \ -I$(ACE_ROOT)\ -I$(HLM_ROOT)/include\ -D_GNU_SOURCE\ -D__ACE_INLINE__\ -DACE_NTRACE=0\ -DACE_HAS_WCHAR=1 logging_client_SOURCES = \ Logging_Client.cpp logging_client_LDFLAGS = \ -L$(ACE_ROOT)/lib\ -L$(HLM_ROOT)/lib logging_client_LDADD = \ -lACE\ -lHLM This is one sample I use in Linux not in msys though. You can specify whatever you need this way. I don't know if this works same in msys though.. Journeyer ---------------------------------------- Journeyer J. Joh o o s a p r o g r a m m e r a t g m a i l d o t c o m ---------------------------------------- 2013/7/6 Kirk Joppy

...

I didn't use pkg-config. I didn't copy any header or library files of boost. I specified those paths on the IDE, code::blocks.

I see. So you don't use autotools but rather use Code::Blocks on both Windows and Linux. This may be a good option. I started using Code::Blocks in the beginning but stopped because the project I'm trying to build is distributed with autotools files for building. Maybe the right strategy is to instead use an IDE to drive the build. Thanks for the suggestion. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

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