Re: [jamboost] Re: runtime-link

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 10:41:06

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

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

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

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

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.

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