Boost Testing :
Subject: Re: [Boost-testing] setup to test mngw- ...
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-10-18 21:20:40
On 10/18/2017 12:21 PM, Robert Ramey via Boost-Testing wrote:
> I've been working to get out one last issue with the boost serialization
> library related to code visibility.Â It shows up on only one platform.
> That is gcc-mngw-gnu on the boost develop test matrix.Â So I conjured up
> a windows machine and I want to run these tests locally.Â I'm really
> confused about what software I have to install in order replicate the
> behavior on the test matrix.Â If I google mngw it seems that there are
> multiple distributions using this name.Â I tried one one but I
> downloaded the compiler first and then msys and tried to run "bootstrap"
> but was unsuccessful.Â I need some advice on how to do this.
> I did manage to implement the above procedure with Cygwin which found
> found an unrelated bug.Â So I'm confident I'm on the right track.Â But I
> need help and would appreciate information from anyone who has done this.
Here is my recipe for using mingw/gcc under Windows:
1) Do not bother with mingw, just use mingw-64.
2) Go to https://sourceforge.net/projects/mingw-w64/
3) Click on the green rectangle that says
4) This should download the file to your hard drive somewhere. Put this
file away somewhere so that you can invoke it a number of times.
5) Execute mingw-w64-install.exe,. click Next, and choose which version
you want to install. Currently you can install any gcc version from
4.8.1 through 7.1.0, and 32 and 64-bit versions.
6) When you install it will suggest a path, but since that path has
spaces, I always override it to a path with no spaces. Boost Build is
famous for problems regarding spaces in a file specification so I never
install anything I will be using with Boost Build to a path with spaces.
You would be wise to do the same.
7) Once installed the setup in user-config.jam will look like:
using gcc : 7.1 :
You can pick and choose which cxxflags you want, but that is my list.
8) Now comes the difficult part which I know you are not going to like.
Just don't curse me, but curse mingw-64/gcc instead. In order to
compile, link, or run, the gcc bin directory must be in your Windows
PATH; it is not good enough to execute g++ from the correct directory.
This is a major PITA, because whenever you invoke, as above 'b2
better be in your PATH or else nothing will work because gcc-7.1 will
not find what it needs.
9) Furthermore b2 used to test every toolset in user-config.jam even if
you were not invoking that toolset via a 'b2 toolset=something". This
meant that if you had multiple gcc toolsets in your user-config.jam for
gcc, the b2 invocation would fail because it is impossible to have the
bin directory for all those multiple toolsets first in your PATH at the
same time. I believe Steve Watanabe fixed this but I am not sure.
10) So my setup, when using a version of gcc as the toolset is that I
have a separately named user-config.jam for each gcc toolset, with names
like user-config.gcc-7.1 etc, and then before invoking the gcc toolset I
do a symbolic link to user-config.jam from user-config.gcc-7.1 etc and
then I invoke 'b2 toolset=gcc-7.1 ...".
11) You can complain to mingw-64/gcc ( it is even worse with mingw/gcc,
but almost no one uses that anymore ) about the stupidity of requiring
the particular mingw-64 bin directory to be in the Windows PATH in order
that the g++ command finds the libraries and include files and whatever
else it needs in order to compile, link, or run an executable; but they
will not care and just cite to you that VC++ sort of does the same.
That is my recipe ! If you have any questions about it please ask and I
will try to help you mas much as I can.
> Robert Ramey