Re: [jamboost] Re: runtime-link

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 12:36:31

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> 
>> Let's just be clear: you can't mix object code with different runtime
>> library settings when linking _statically_.
>> 
>> 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.

>>>At least <link>static and <link>shared are link compatible, and
>>>code which uses static zlib is compatible with code which uses
>>>shared zlib.
>> 
>> 
>> 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
>> intention better.
>
> 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?",
"rebuildable?"

>> 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.

>>>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?

> <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.

>> 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
> libraries.
>
> 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
data).

>>> 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.

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution