From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-05 13:21:29
David Abrahams wrote:
>>>It's tricky but possible to do it within one running program as long
>>>as each executable or DLL uses one consistent setting.
>>Okay, noted. We probably should not think about this tricky case
>>until we've settled eveverythin else.
> I don't agree. It's slightly tricky, but very common.
The question is really whether <runtime-link> is link compatible or not.
And it's orthogonal to all the other discussion, that why I suggest
to leave it out for a moment.
>>>>At least <link>static and <link>shared are link compatible, and
>>>>code which uses static zlib is compatible with code which uses
>>>I'm not sure whether you're referring to v1, v2, some hypothetical v2,
>>>or "real life" here.
>>I'm talking about v2 with Rene's <link> suggestion.
> Oh well, I'm still lost at this point. Let's drop it unless you think
> it's important.
>>>Maybe we should be calling these things "installed" or "prebuilt"
>>>libraries rather than "system libraries". I think it captures your
>>Or "external" libraries. Let's use this term, as opposed to "internal".
> I could live with that, but...
> I think internal/external are not very descriptive terms, especially
> when multiple projects are involved, and most especially for new
> users. I'd prefer "prebuilt" and something else... "boost built?",
I get your point. You're right, with several project "external"
can mean anything. I'll try to come with a better name for
>>>Your honor, I object!
>>>The whole *point* was to hide the fact that it's a minor detail on
>>>Linux but a major one on Windows from users. Why should users care if
>>>a special compilation mode is needed on Windows?
>>OK, I see your intention. But the question is wether we should extend
>>its semantic to cover external libraries. On Linux, linking to
>>runtime and to external libraries is most often the the same.
>>On Windows? If the situation is the same, then we'd better
>>avoid separate features.
> It seems as though Windows certainly needs separate features.
No sure still, see below.
>>>>The <link> proposal works very nice for unix.
>>>I'm not convinced it's even very well-defined yet.
>>Let's ignore the issue of <shared> propagation. Then:
>><link>shared makes all internal libraries shared
>>and all external dynamic (if possible)
> ?? shared == dynamic, no?
Yes, I mean that both internal and external are shared/dynamic.
>><link>static makes all internal libraries static,
>>and all external are still dynamic
>><link>all-static makes everything static.
> Those sound like common approaches for linux.
>>The issue is whether <link>all-static can behave this
>>way on windows, you we'd need another feature or
>>set of values to control runtime link.
> If <link> is really a composite feature, I think there's no problem.
Yes, that's very reasonable idea.
>>>You might want to ship self-contained DLLs which don't depend on other
>>>things installed on the system.
>>>> - Is it ever desirable to use static runtime and link to
>>>> zlib's dll?
>>>Yes, for the same reasons.
>>I don't understand. If you depend on zlib's dll, your dll is no
>>longer self contained, unless you ship zlib with it.
> You might be shipping an executable or DLL using the static runtime,
> for reasons stated above, and linking dynamically to a 3rd-party
> vendor's dll (in place of zlib) which is available only as a DLL.
>>>> Or, generally, use static runtime and
>>>> link dynamically to all libraries that are
>>>> assumed to exit on system?
>>>Please clarify which libraries those might be.
>>Say I use 10 external libraries available in binary form (both
>>static and dynamic). I wrote a DLL that uses all of them. I might
>>want to ship an entirely self contained version of this DLL, in
>>which case I must link statically to runtime and all 10 external
>>I might want to ship needed libraries together with DLL,
>>in which case I can use dynamic runtime and ship that too.
>>Why should I use static runtime but dynamic version of
>>those 10 libraries?
> All 10? I can't think of a reason. For one library, it might be
> something like the Boost.Python library, which manages plugins and
> interactions between them. In that case, it might be important to have
> a single repository of some central information (i.e. the DLL's global
That's it! If you can't think of a reason then "all-static" can
make all external libraries static. The ones available only
as DLLs will be handled specially. For example, declaration
of target will say that it's always DLL.
We can introduce a win-specific feature which controls runtime-link
separately, and make "all-static" contain <runtime-link>false,
as you suggest. I'll leave it to Win32 users to decide.
What's important, is that plain <link>all-static will do
the same thing both on Linux and Windows.
>>>> If the second situation is not common, then <link>all-static will
>>>> use static runtime on MVSC. It will also be link incompatible with
>>>> other values for <link>. At the same time both <link>shared and
>>>> <link>static would use dynamic runtime and be link compatible
>>>> between each other.
>>>The whole thing sounds confusing and messy to me. It's going to take
>>>some work to convince me of this. Maybe it's just the choice of names,
>>>but I don't think so.
>>Let's decide if the "static runtime, dynamic external libraries" use
>>case is common enough. Everything else will depend on it.
> I don't know how common it is. It doesn't need to be easy to specify
> this, just possible.
It is possible. If the only declaration for zlib is
system-lib zlib : <file>.... <link>shared ;
then it will cause dynamic linking of zlib in all cases.
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