Boost logo

Boost-Build :

Subject: Re: [Boost-build] Native-built tools in a cross-compile environment
From: Kylo Ginsberg (kylo_at_[hidden])
Date: 2012-10-22 20:03:13


Ok I spoke too soon. That solution works *except* for the following:

The tool is linked against static libraries, and I have a target
shared library which uses that tool. For reasons I don't follow, the
cross build of that shared library ends up linking against *native*
versions of those static libraries. Strange.

I'm whittling this down to a standalone case, with a tool 'text-to-c'
and a library 'screwball':

user-config.jam contains:

--------
if [ os.name ] = LINUX {
    using gcc : native : gcc ;
    using gcc : granite : /path/to/cross/toolchain/bin/x86_64-linux-gcc ;
}
--------

Jamroot:

--------
import build-tools ;
path-constant JAMROOT : . ;
use-project /build-tools : build_tools ;
use-project /boost : boost/boost_1_51_0 ;
path-constant BUILD_DIR : $(JAMROOT)/build/boost_1.51.0 ;
project : requirements : build-dir $(BUILD_DIR) ;
--------

build_tools/Jamfile:

--------
import feature ;
import os ;
import toolset ;

feature.feature native-build : on : optional propagated ;
if [ os.name ] = LINUX {
    toolset.add-requirements <native-build>on:<toolset>gcc-native ;
}

alias text-to-c : text_to_c//text-to-c ;
--------

build_tools/text_to_c/Jamfile:

--------
project : requirements -<text-to-c>text-to-c ;

exe text-to-c : text_to_c.cpp
                /boost/thread//boost_thread/<link>static
              : <native-build>on
;
--------

And screwball/Jamfile:

--------
import build-tools ;

project : requirements <text-to-c>/build-tools//text-to-c ;

lib screwball : foo.cpp : <link>shared ;
--------

If I remove the tool linking against boost_thread, no native libs show
up in the link of screwball.so.

Does any of this look obviously wrong? Any hints on where else I should look?

TIA
Kylo

On Fri, Oct 19, 2012 at 10:48 AM, Kylo Ginsberg <kylo_at_[hidden]> wrote:
> Perfect! Thanks so much!!
>
> On Fri, Oct 19, 2012 at 7:34 AM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>> AMDG
>>
>> On 10/15/2012 05:53 PM, Kylo Ginsberg wrote:
>>> I have ported a project using boost-build from Windows (using msvc) to
>>> Linux (using gcc), and am now porting it further to a cross-compiled
>>> Linux (also using gcc). I want to support all 3 platforms long-term
>>> (Windows, native Linux, cross-compiled Linux).
>>>
>>> I've put in the basic support for cross-compilation, simply by adding
>>> a new "using gcc ..." line. However, this project uses some
>>> code-generating build tools which are built afresh with every build --
>>> with my current basic support for cross-compilation, these build tools
>>> are cross-built and thus don't run on the build machine. In short,
>>> these need to be native built at all times and I'm not sure how best
>>> to specify this. Is there a best practice for this scenario?
>>>
>>> I can certainly provide more detail on the organization of the
>>> Jamfiles, etc, but figured I'd start with a short-ish note ;>
>>>
>>
>> # user-config.jam
>> using msvc ;
>> using gcc ;
>> import toolset ;
>> # globally force the toolset to msvc when building
>> # for windows
>> toolset.add-requirements <target-os>windows:<toolset>msvc ;
>>
>> # Jamfile
>>
>> # force target-os to be the same as host-os
>> rule native-tool ( properties * )
>> {
>> local host = [ property.select <host-os> : $(properties) ] ;
>> return <target-os>$(host:G=) ;
>> }
>>
>> exe tool : tool.cpp : <conditional>@native-tool ;
>>
>> If <target-os> isn't sufficient to distinguish
>> the host from the target, you can define a new
>> feature:
>>
>> import feature ;
>> import toolset ;
>> feature.feature native-build : on : optional propagated ;
>> toolset.add-requirements <native-build>on:<toolset>gcc-4.7.2 ;
>>
>> ...
>>
>> exe tool : tool.cpp : <native-build>on ;
>>
>> In Christ,
>> Steven Watanabe
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build


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