From: Edward Diener (eldiener_at_[hidden])
Date: 2019-08-01 00:26:14
On 7/31/2019 1:06 PM, Maarten Verhage via Boost-build wrote:
> Hi Edward,
>>> Here are the things I think you need to do to do this:
>>> 1) Get the latest Boost from Github into a directory and then run these
>>> comamnds from that directory:
>>> 2) git checkout develop
>>> 3) git pull
>>> 4) get submodule update --init
>>> 5) git submodule foreach --recursive git checkout develop
>>> 6) git submodule foreach --recursive git pull
>>> 7) ./bootstrap.bat to create the latest b2
>>> 8) ./b2 headers
>>> 10) cd to the Spirit test directory
>>> 11) ../../../b2 toolset=gcc-8.1 etc.
> I prefered to continue using boost 1.69 as the main library. But I did a
> Github clone of
> just the Boost-build develop library and did the above steps on that.
If you use Boost 1.69 as the distribution you want to test you must
build b2 for that distribution, and then use the version of b2 you
create to test the Spirit library in 1.69. This is what I meant by not
mixing Boost Build/b2 built in a particular Boost distribution with a
library in another distribution which you are trying to test. This can
be done because the './bootstrap.bat' command in Windows generates
'b2.exe' in the top-level directory of a distribution. It is asking for
trouble if you try to use a version of b2 created by one Boost
distribution to build/run tests for a different Boost distribution. Why
do it even if it might actually seem to work.
>>> The last step needs an appropriate entry for the gcc-8.1 toolset in your
>>> user-config.jam. My user-config.jam entry for running gcc-8.1 in 32-bit
>>> mode is:
> The mingw-w64 library I use is x86_64-8.1.0-release-win32-seh-rt_v6-rev0.
> In the bootstrap build of boost-build I switched temporarily to the
> posix-seh variant (this has to do with thread support). But the build of b2
> was succesful.
> I do have a problem with the last part of your instructions. The only
> user-config.jam file is located in the folder <path-to-boost-build>\example,
> do you mean I use that one somehow? Additionally for the mingw-w64 version I
> use I don't have a cp_gcc81.bat file.
> If I run b2 now in the spirit\test folder I still get the:
> config.jam: No such file of directory
> followed be the same stuff as output.txt in the attachment of my first post
> Are you willing to explain a bit more on what is happening? Then you can
> give me a chance to apply my own judgement as how to attack this problem. As
> I'm now under the impression that this new b2.exe file is not solving
>> using gcc : 8.1 :
>> "$(TSE_BATCH_DRIVE)/programming/bat/cp_gcc81.bat" :
If you have mingw-w64/gcc-8.1 in your Windows PATH before any other
Windows gcc distribution you might have installed then you don't need a
user-config.jam entry for that toolset unless you want to also set
certain compilation/link options using a toolset definition.
In my particular case I have more than one mingw-w64/gcc distribution
installed ( fifteen versions actually, with 32bit and 64bit distros for
each version ) which I can theoretically test against any given Boost
library, so it is useless for me to rely on a single PATH and no
user-config.jam in order to run tests. So in my setup what I have is a
user-config.jam entry for each version. The toolset definition command I
then use for each toolset definition is therefore a script which
prepends that version's mingw-w64/gcc bin directory to the Windows PATH
and then invokes g++ passing all the parameters which are passed to the
script. My script in the example above for mingw-w64/gcc-8.1 is a
Windows batch file although of course you could use whatever you wanted
such as Python or Perl scripts if you liked. That is what my
cp_gcc81.bat does in the toolset definition above. Furthermore again,
because I don't have a single version of mingw-w64/gcc in my Windows
PATH, I need to specify in my toolset definition the path to the
particular mingw-w64/gcc's root directory at runtime so any necessary
DLLs will be found when b2 encounters the 'run' ( or 'run-fail' ) action
in a library's tests. This is what my <root> option does above. Please
disregard the $(TSE_BATCH_DRIVE) and $(TSE_MINGW64_DRIVE) above as they
just substitute some drive letter ( such as 'C:' ), for my setup through
bjam variables I initially set. Why I do this rather than just
specifying 'C:/etc.' or 'E:/etc.' in the toolset definition is too
tedious to explain and has no importance in this explanation.
Finally the rules I have found with mingw-w64/gcc distributions are:
1) You can't use a 64-bit distribution to compile 32-bit code because,
for whatever reason, the linker used does not find the appropriate
32-bit libraries needed during the linking phase. I don't have the time
or patience to figure out why this is so, therefore I use the
appropriate mingw-w64/gcc version's 32-bit distribution to compile/link
32-bit code and the appropriate mingw-w64/gcc version's 64-bit
distribution to compile/link 64-bit code. A real PITA but what can you do.
2) The bin directory of a given distribution must be in the Windows
PATH, or be the current directory, in order to compile/link
successfully. Just specifying the full path to the g++ command is not
enough. Fight with the gcc or mingw-w64 developers about this if you
like. Their answer to me is that VC++ does the same so they do it also,
although what I believe VC++ does is set environment variables to find
what it needs at compile/link time.
3) At runtime the bin directory of a given distribution often has
run-time DLLs which must be found in order for dynamically linked exes
to run correctly. This is at least normal when some application does not
install their DLLs in the PATH, such as in the Windows or Windows/system
directories or more modernly use a manifest, such as VC++ does.
Hopefully this helps you but if you have any questions feel free to ask.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk