Re: runtime-link

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-12-05 12:00:47

Vladimir Prus wrote:
> Markus Schöpflin wrote:
> 
>> David Abrahams wrote:
>> 
>>> I think there was much confusion about the meaning of 
>>> runtime-link in v1; many people thought they should set it to 
>>> dynamic in order to build a shared library. I am concerned 
>>> about the name "link" being even more confusable in that same 
>>> way.
>> 
>> I'm sorry, but I fail to see how the current suggestion can model
>> the behaviour of runtime-link as it works in v1.
> 
> <link>shared would mean "link everything, including runtime, as 
> dll"
> 
> <link>all-static would mean "link everythin, including runtime, as
> static lib".

This doesn't make much sense on windows where you can't link
statically to the system libs (like gdi32, user32, ...)

>> For MSVC, it currently controls the addition of /MD(d), ML(d) or
>> /MT(d) to the compiler command line. It's a flag used at compile
>> time and it affects the object code generated. You can't mix 
>> object code with different runtime library settings when linking.
>> 
>> 
> 
> Which means that objects built <link>all-static would be 
> incompatible with objects built with <link>shared. Hmm.. I don't 
> link that idea.

That's why I suggested another flag for this.

> At least <link>static and <link>shared are link compatible, and 
> code which uses static zlib is compatible with code which uses 
> shared zlib.

As long as the static or dynamic zlib uses the same C runtime you use
for your own code.

Lets make a little example. Say, as a vendor, you want to distribute
prebuilt static libraries to your customers. Then you have to deliver
six(!) different versions.

The versions are: single threaded static runtime, multi threaded
static runtime and multi threaded dynamic runtime and each one in a
debug and a release build.

For a DLL you can do better if you're careful enough. If no
dynamically allocated memory crosses the DLL boundary and if you're
aware of the fact that each runtime model get's it's own copy of
static variables you only need on build.

>> 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.
> 
>> 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. That's why I do not want to see 
> <runtime-link> in target paths.
> 
> The <link> proposal works very nice for unix. 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.

Yes, it just tells the build system that it should select the
appropriate runtime version of the shared or static library.

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

If the zlib lib was built using the static runtime you have to use the 
static runtime.

> - Is it ever desirable to use static runtime and link to zlib's
> dll?

If the zlib dll is designed accordingly, you can select whatever 
runtime you like. Static, dynamic or multithreaded dynamic.

> Or, generally, use static runtime and link dynamically to all
> libraries that are assumed to exit on system?

Let me rephrase things a bit. The runtime model you use doesn't tell 
you if you have to link to other libs statically or dynamically. It 
just enforces a specific version of the other library.

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

I don't know. I think we have to ortogonal features here.

1. Which runtime library model should I use? Single threaded static, 
multi threaded static or multi threaded DLL.

2. How do I want to link to other libraries by default? Statically or 
dynamically?

Markus