Re: runtime-link

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-05 12:21:55

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.

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

>>>This has nothing to do with linking to the system libraries, like 
>>>gdi32 or user32. You only select if you want debug or release builds 
>>>for those, there is no choice for static or dynamic linking, AFAIK.
>>
>>I did not meant *those* libraries --- they are almost runtime.
>>I meant libraries like zlib, or expat, which can be installed
>>on system, but are not part of OS.
> 
> 
> 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".

>>>On the other hand, if you link to a DLL that uses the dynamic C 
>>>runtime (/MT(d)) you should link your application using the dynamic C 
>>>runtime as well, at least this is what Microsoft recommends. This 
>>>means, that if you link with MFC for example, you have to use /MT(d) 
>>>when compiling your code, not just when linking.
>>>
>>>Maybe we need a completely different (ms specific) flag for this? 
>>>After all, it's a problem that only occurs on windows platforms.
>>
>>This might be a good idea, after all. The original problem is
>>that <runtime-link> was overloaded. On windows platforms it
>>mean a special mode of compiling. On gcc it mean only how
>>C runtime was linked -- a fairly minor detail. 
> 
> 
> 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.

>>That's why I do not want to see <runtime-link> in target paths.
> 
> 
> I think that's a completely separate issue, and we can make that
> choice independently. It can also be platform-dependent.

OK.

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

<link>static makes all internal libraries static,
and all external are still dynamic

<link>all-static makes everything static.

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.

>>Let's see if it can be extended.
>>
>>1. It appears that <runtime-link> does not affect the choice
>> of whether internal libraries are shared or static.
>>2. I'm not sure how it's related to linking of standard libraries.
>> Say MSVC runtime can be either shared or static, with shared
>> been the default. Say that we expect some library, zlib,
>> to be available on build host, both as lib and dll.
>>
>> - Why one would want to use static runtime? (Just curious)
> 
> 
> 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.

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

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

- Volodya