Re: [jamboost] Re: runtime-link

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-05 10:54:38

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

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

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

> 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.
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)
- Is it ever desirable to use static runtime and link to
zlib's dll? Or, generally, use static runtime and
link dynamically to all libraries that are
assumed to exit on system?

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.

- Volodya