Re: [Boost-build] How to build project comprising of sources in different dirs

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-06-07 14:31:20

   Hi Frank.

   Ok, I finally got some time to play around with this some more.

   The non-working example you sent in your previous post can be 
represented like this (targets for which the link property is not 
specified have it set to shared):

> --- Main (exe)
>     |
>     |--- Common (alias)
>     |   |
>     |   |--- CommonLib (library) <link>static
>     |   |   |
>     |   |   |--- Utils (alias) <link>static
>     |   |       |
>     |   |       |--- UtilsLib (library) <link>static
>     |   |       |
>     |   |       |--- date_time (library) <link>static
>     |   |
>     |   |--- date_time (library) <link>shared
>     |
>     |--- Utils (alias)
>         |
>         |--- UtilsLib (library) <link>static
>         |
>         |--- date_time (library)

   Now since in your model you link to the date_time library twice - 
once as a static library and once as a shared library it is 
understandable why this does not link as you have one static library 
CommonLib containing exported references to date_time symbols coming 
from a static date_time library and then your main executable has those 
symbols available from both the static CommonLib library and the shared 
date_time library.

   On the other hand, I do not understand why GCC compiles. It has 
equivalent symbols defined in CommonLib static library and the date_time 
shared library but somehow manages to choose which symbols to map.

   I tried working around the problem by forcing CommonLib to link to the
shared date_time library by setting the <link>shared property explicitly 
for the Utils alias when listing it as a source for the CommonLib 
target. That gave me the following diagram (explicitly marked targets 
whose <link> property changed from the previous example using 
***NOW-SHARED***):

> --- Main (exe)
>     |
>     |--- Common (alias)
>     |   |
>     |   |--- CommonLib (library) <link>static
>     |   |   |
>     |   |   |--- Utils (alias) ***NOW-SHARED***
>     |   |       |
>     |   |       |--- UtilsLib (library) <link>static
>     |   |       |
>     |   |       |--- date_time (library) ***NOW-SHARED***
>     |   |
>     |   |--- date_time (library)
>     |
>     |--- Utils (alias)
>         |
>         |--- UtilsLib (library) <link>static
>         |
>         |--- date_time (library)

   Unfortunately this did not make MSVC build successfully either even 
though it uses only a single shared date_time library.

   I then tried reproducing an equivalent problem using only shared 
libraries by without using boost libraries and was unsuccessful. I could 
not get it to fail... and whatever I did the behavior was 'logical' and 
build either failed on both gcc & msvc or succeeded on both. I'll try 
again when I get enough time to trim down the boost library sources.

   One 'interesting' fact I noticed is that msvc linker complains only 
about two symbols that representing inline member functions defined in 
header files. Could not make use of this in my own example though.

   I'll let you know when I get time to look into this again. So far I 
have not been able to look into your 'bundle' construct.

   Best regards,
     Jurko Gospodnetić