Re: [jamboost] Re: runtime-link

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 11:22:01

Vladimir Prus <ghost_at_[hidden]> writes:

> Markus Schöpflin wrote:
>
>> 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.

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.

> Which means that objects built <link>all-static would be incompatible
> with objects built with <link>shared. Hmm.. I don't link that idea.
<g>---------------------------------------------------^^^^

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

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

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

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

> The <link> proposal works very nice for unix. 

I'm not convinced it's even very well-defined yet.

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

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

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

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