Re: runtime-link

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

OK.

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

I get your point. You're right, with several project "external"
can mean anything. I'll try to come with a better name for
"internal", then.

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

OK.

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

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.

- Volodya