Re: [Boost-build] Dependency on shared library from static library(mixing shared and static libs)

Subject: Re: [Boost-build] Dependency on shared library from static library(mixing shared and static libs)
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2009-02-03 12:30:28

Alexander Sack wrote:
> On Tue, Feb 3, 2009 at 8:21 AM, Johan Nilsson
> <r.johan.nilsson_at_[hidden]> wrote:
>> Hi,
>>
>> consider the following:
>>
>> - Library "a" that can be built for shared or static linking.
>> - Library "b" depends on "a", but can only be built for static
>> linking.
>> - App "c" depends (directly) on "b".
>>
>> All the above are defined as Boost.Build targets within a single
>> project.
>>
>> I would like to be able to:
>>
>> 1. Build app "c" to use the shared version of "a" (e.g. bjam
>> link=shared):
>>   - Link statically to "b" (as this is the only possibility)
>>   - Link shared to "a"
>>   - Lib "b" should reference the shared build of "a"
>
> Well I believe static libb can't be linked with shared a.

Well, obviously a static lib can't be linked (at least not with msvc). Hence 
the "... _reference_ the shared build of a" (which could be even more 
specific by stating "contains references to the functions exported by the 
shared build of a", perhaps).

>  That
> doesn't make sense to me.  See here for more linkage info with respect
> to Boost.Build:
>
> http://www.boost.org/doc/tools/build/doc/html/bbv2/tutorial/linkage.html
>
>> 2. Build app "c" to use the static version of "a" (e.g. bjam
>> link=static):
>>   - Link statically to "b"
>>   - Link statically to "a"
>>   - Lib "b" should reference the static build of "a"
>
> This is what I did with your Jamroot and got results which I *think*
> are what you want:
>
> project foo ;
>
> # can be built as static or shared library
> lib a : a.cpp : <link>shared:<define>A_BUILD_DLL : :
> <link>shared:<define>A_BUILD_DLL ;

That is most definitely not what I want (your modified usage requirements).

>
> # can only be built as static library
> lib b : b.cpp a : <link>static ;

I'm not sure why a should be a source here. What's the semantic difference?

>
> exe c : c.cpp b a ;

Here as well. For me it's really not intuitive that a library is part of the 
application's sources.

>
> I was able to produce an executable c which was either statically
> linked with both liba and libb or dependent on just liba:
>
> # ldd bin/gcc-3.4.4/debug/c
> bin/gcc-3.4.4/debug/c:
> liba.so => /root/shared_static_libs/bin/gcc-3.4.4/debug/liba.so
> (0x80062a000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x80072b000)
> libm.so.4 => /lib/libm.so.4 (0x800922000)
> libc.so.6 => /lib/libc.so.6 (0x800a3e000)
> # ldd bin/gcc-3.4.4/debug/link-static/c
> bin/gcc-3.4.4/debug/link-static/c:
> libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x80062a000)
> libm.so.4 => /lib/libm.so.4 (0x800821000)
> libc.so.6 => /lib/libc.so.6 (0x80093d000)

I'm a bit surprised that you managed to build the unmodified sources using 
gcc - is that really a fact? Please note though, that using shared libraries 
under windows is a different beast than under linux using gcc.

Thanks for you reply, nevertheless.

/ Johan