Re: [Boost-build] Need some help running library tests

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
> here.
> 
> 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
> anything.
> 
>> using gcc : 8.1 :
>>      "$(TSE_BATCH_DRIVE)/programming/bat/cp_gcc81.bat" :
>>      <cxxflags>-Wno-unused-local-typedefs
>>      <cxxflags>-ftrack-macro-expansion=0
>>      <cxxflags>-Wno-unused-variable
>>      <cxxflags>-D_GLIBCXX_USE_CXX11_ABI=1
>>
>> <root>"$(TSE_MINGW64_DRIVE)/Utilities/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32"
>>      ;

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.