Re: [Boost-build] Simple bjam question: linking in boost libraries?

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-07-02 13:21:21

Reece Dunn wrote:
> You'd be better switching over to Boost Build V2 as V1 is being phased
> out. In V2, this would be:
> 
>    exe mfront
>      :
>        ./driver/driver.cpp ./main.cpp ./parser/generator.cpp 
>        $(BOOST_ROOT)//filesystem
>        $(BOOST_ROOT)//wave
>      ;
> 
> This might work for V1: i.e. replacing <lib>wave with either
> <lib>boost//wave or <lib>$(BOOST_ROOT)//wave, but I don't
> know enough about V1 to confirm that this is correct.

While this might work, the concept does look somewhat strange to me.
You need the source of boost available, true?

I am looking for a way to specify the boost libraries to link with
similar to what autolinking will do on capable platforms.

What is needed is having something like
        <find-boost-library>filesystem
automatically expanding to a linker switch something like
e.g. for gcc: -lboost_filesystem-gcc-mt-d-1_34

I have tried something:

rule find-boost-library-variant
     ( toolset variant : subvariant-path properties * )
{
        local libtag ;
        libtag = [ common-variant-tag $(toolset) $(variant) : 		
             $(subvariant-path) $(properties) ] ;
        libtag = [ MATCH "<[*]><[*]><tag><prefix>"(.*) : $(libtag) ] ;
        local p prop ;
        for p in $(properties) {
                local m ;
                m = [ MATCH "<find-library>boost_"(.*) : $(p) ] ;
                if ( $(m) )
                {
                        prop += <find-library>boost_$(m)$(libtag) ;
                }
                else {
                        prop += $(p) ;
                }
        }
        return $(subvariant-path) $(prop) ;
}

exe hello
        : hello.cpp
        : <sysinclude>/usr/local/include/boost-1_35
          find-boost-library-variant
          <find-library>boost_thread
          <runtime-link>dynamic
        : <threading>multi
        ;

The problem with the above code is, that if I use
<runtime-link>static it will generate a linker switch
-static -lboost_thread-gcc-mt-sd
which id bad, since the correct should be boost_thread-gcc-mt-d .

The question I am pondering with is: What is the meaning of
<runtime-link>static when used on an exe target?

As it appears it seems to emit the -static switch for gcc.

Tracking this futher looks like a deeper semantic problem:

On windows <runtime-link>static means that the final target
should be linked with the static version of the C-runtime
library.
I.e: flags msvc CFLAGS <runtime-link>static : /ML ;

On Linux (gcc) <runtime-link>static means that all -l switches should 
select the static library versions. (Has nothing to do with C-runtime)
I.e: flags gcc LINKFLAGS <runtime-link>static : -static ;

Any ideas?

Roland