Re: [boost] Re: [thread] Why is there a restriction for theruntimelibraries?

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2004-12-07 00:45:21

Edward Diener wrote:

>Stefan Slapeta wrote:
>  
>
>>Michael Glassford wrote:
>>    
>>
>>>Perhaps I missed something, but did you determine why it isn't being
>>>built?
>>>      
>>>
>>Yes, this was the reason for my original posting. If there are no
>>objections, I'll commit these changes. I'm sure the restrictions below
>>just exist for historical reasons (I can't explain either why e.g. a
>>static boost.thread library shouldn't use a dynamic rt).
>>    
>>
>
>Despite the fact that other Boost libs have their static libs use a dynamic
>RTL there is a reason to do otherwise. Many programmers have historically
>wanted to build a single executable without any shared libraries for their
>application. This can be done if the static libs used by that executable all
>use the static RTL. Once one of those static libs uses the dynamic RTL it is
>no longer possible to do this, and there is no way, using such a library, to
>build a single executable that can be distributed without any shared
>libraries.
>  
>
I am not sure about what exactly you are talking, so I try to clarify:

1) MyApp using static runtime.
    a) MyApp using static boost lib
        --> link in: libboost_thread-*-mt-s??-1_32.lib
    b) MyApp using dynamic boost lib
        --> probably not a good idea
2) MyApp using dynamic runtime:
   a) My App using static boost lib
        --> link in: libboost_thread-*-mt-??-1_32.lib
    b) MyApp using dynamic boost lib
        --> link in: boost_thread-*-mt-??-1_32.lib

As you can see 1a) is your requested case. But nothing should prevent a 
user to choose 2a) if she decides.
The original observation was that case 2a) isn't currently available. I 
don't think you are advocationg for
not allowing for case 2a) aren't you?
BTW.: Only case 1b) will result in using two instances of the RTL lib 
which is considered bad.

>I do not so much mind that other people disagree with me about having static
>libs use the static RTL and shared libs ( dlls on Windows ) use the dynamic
>RTL, but I do mind it when others can not understand the simple argument,
>whether agreed with or not, I have just specified as a reason for doing so.
>  
>
Most of the recent effort has been to restore exactly what you want. In 
1-31 only case 2b) was available
with full features.

>Of course if Boost does not feel that they have to cater to those wishing to
>build a single executable without any shared libraries, that is fine with
>me. I just want to point out that if the default situation is to have static
>libs use the static RTL and shared libs use the dynamic RTL, developers can
>get the best of both worlds; either a single monolithic executable or an
>executable where all libraries are shared, depending on whether they choose
>to use static libs or shared libs when building their application.
>  
>
Now they even have a third option too (2a). The whole issue is not about 
taking away options but to add
missing ones. The only question was what are the defaults:
When user chooses 1) --> default is 1a)
When user chooses 2) --> default is 2a) (altough I would rather like 2b, 
but this I have been told is against boost standards)

Roland