Re: runtime-link

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

David Abrahams wrote:

> Markus Schöpflin<markus.schoepflin_at_[hidden]> writes:
> 
>> 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.
>> 
>> 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.
>> 
>> 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.
> 
> OK.
> 
> I think there are a few vagaries which, if cleared up, would help
> us understand what we're talking about:
> 
> 1. What is the definition of "system library"?

Good question. All libs provided by the manufacturer of the system? 
Maybe we should only distinguish between libs built with boost build 
and libs living outside the scope of boost build. Maybe call them 
"external" or something like that.

> 2. Is this feature meant to express a preference or a hard 
> requirement?

This can only be answered after we have an agreement of what this 
feature really should mean.

>> 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.
> 
> Yes, nearly always. Of course, there are exceptions. A dynamic
> library can be (and often is) organized to manage all of its own
> resources, so it is isolated from the issues that occur when you
> use different runtimes on both sides of the boundary. For example,
> if you pass all resources via boost::shared_ptr<> ;-)

I don't get it. Do you mean, if you use shared_ptr<>, you don't have a 
problem with the DLL boundary. I would doubt this.

>> This means, that if you link with MFC for example, you have to
>> use /MT(d) when compiling your code, not just when linking.
> 
> Right.
> 
>> Maybe we need a completely different (ms specific) flag for this?
>> After all, it's a problem that only occurs on windows platforms.
>
> The issue of link-compatibility between objects compiled for
> different runtimes only occurs on Windows, but the issue of whether
> to link to the static or dynamic runtime certainly comes up on
> other platforms.

True.

> I understand that eventually we need to deal with platform-specific
> needs, so I am certainly willing to consider this. However, I only
> want to go this direction as a last resort. An important design
> goal of Boost.Build is to be able to write "high-level" build 
> specifications which mostly insulate the user from 
> platform-/compiler-specific issues. If we can capture the "usual 
> intention" of the user in asking for a static or dynamic runtime
> such that it chooses the right compiler option on Windows and does 
> something else everywhere else, that's better.

Ok, then let's make two ortogonal features of this. (See my answer to 
Vladimir for details.)

Markus

PS: Here is the reference documentation from MS on those compiler 
flags: 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.MD.2c_2f.ML.2c_2f.MT.2c_2f.LD.asp