Boost C++ Libraries: Ticket #9704: b2: Compiler flavour has no flexibility for cross-compiling projects.

status, component changed; owner set

Steven Watanabe — Fri, 04 Apr 2014 19:59:29 GMT

owner set to Steven Watanabe
status new → assigned
component Building Boost → build

Regarding (2), I believe that this used to work. If it's broken, it's probably to try to support uses that set flags for specific versions of gcc, which need the real gcc version number rather than some arbitrary identifier. I'll look into this.

P.S. The correct component for Boost.Build is "build". "Building Boost" is for issues when building the Boost C++ libraries. It's often ambiguous, though and if you use the wrong component it doesn't matter much, since the same people are responsible for both, and we can reassign it if needed.

Steven Watanabe — Fri, 04 Apr 2014 21:09:39 GMT

Replying to lukasz.forynski@…:

import toolset ;
if [ toolset.name ] == gcc
{
  if [ toolset.flavor ] == flav_1
  {
  }
}
<snip>

This is fundamentally impossible in Boost.Build. The main reason being that there is no such thing as the value of a feature in a Jamfile. See http://www.boost.org/boost-build2/doc/html/bbv2/faq.html#bbv2.faq.featurevalue

You would need to write this using a conditional

import feature ;
rule calculate-install-dir ( properties * )
{
    local gcc-version = [ feature.get-values <toolset-gcc:version> : $(properties) ] ;
    return <location>../../release_$(gcc-version) ;
}
install copy_binaries_to_release
  : # target names
  :
    <conditional>@calculate-install-dir
  ;

Steven Watanabe — Fri, 04 Apr 2014 22:13:25 GMT

Replying to lukasz.forynski@…:

Problems:

Different toolset names when building on different OSes (and yes, I did try to specify a default flavor, but see Problem 2).

command toolset flavor
gcc XA32(linux) b2 gcc 4.7
gcc XA32(win) b2 gcc-4.7.2-mingw ?
gcc armhf(linux) b2 --toolset=gcc-armhf gcc armhf
gcc armhf(win) b2 --toolset=gcc-armhf target-os=linux gcc-mingw-armhf ?

Only gcc-armhf seems to achieve requested results. BUt the main issue it, that it is all different on different platforms, and both: armhf should produce compatible binaries.

I'm sorry. I don't understand this table. On line 1, gcc XA32(linux), the properties should be <toolset>gcc <toolset-gcc:version>4.7.2 On line 2, gcc XA32(win), they should be <toolset>gcc <toolset-gcc:version>4.7.2 <toolset-gcc:flavor>mingw. For lines 3-4, just replace 4.7.2 with armhf. I suppose my issue is that I don't see how you're deciding what is the toolset and what is the flavor.

I've been trying several things and the only issue that I ran into using multiple versions of gcc (including a cross-compiler) is the old problem when mixing MinGW with other versions of gcc (All versions of gcc are tagged as mingw).

Here's what I suggest. It seems to work for me with a combination of mingw-w64 and native gcc on linux.

using gcc : 4.7.2 : g++ : <flavor>host ;
using gcc : 4.8.0 : /usr/local/gcc-4.8.0/bin/g++ : <flavor>host ;
using gcc : 4.7.2 : i686-w64-mingw32-g++ : <flavor>mingw ;

Then you can access <toolset-gcc:flavor> to get the flavor. (Adjust the version number, path, and flavor for your environment. If you leave the version blank, it will be auto-deduced.)

Running

# Uses g++
b2
b2 gcc
b2 gcc-4.7.2
b2 gcc-linux
b2 gcc-linux-4.7.2
b2 gcc-4.7.2-linux
# Uses GCC 4.8
b2 gcc-4.8.0
b2 gcc-4.8.0-linux
# Uses MinGW g++
b2 gcc-4.7.2-mingw
b2 gcc-mingw

You have to be a little careful, since Boost.Build is not smart about filling in defaults. It's safest to specify just gcc, which will always take the first version initialized, or to specify the full gcc-version-flavor. (b2 gcc-mingw will break if you put gcc 4.8.0 first, since it becomes gcc-4.8.0-mingw, which doesn't exist.)

	command	toolset	flavor
gcc XA32(linux)	b2	gcc	4.7
gcc XA32(win)	b2	gcc-4.7.2-mingw	?
gcc armhf(linux)	b2 --toolset=gcc-armhf	gcc	armhf
gcc armhf(win)	b2 --toolset=gcc-armhf target-os=linux	gcc-mingw-armhf	?