Re: runtime-link

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-05 11:49:28

David Abrahams wrote:

> I don't think we're saying the same thing.
> 
> It is possible to build a shared library which links statically to its
> dependencies, is it not? This is an important usage model, at least on
> Windows, where shared library vendors want to reduce the chance that
> the installation of some newer (or older) shared "system" library
> version will break their product in the field.

I can see three solutions:

1. Specify <static>false in requirements for those libraries
2. Explicitly specify <static> when referring to those libraries:

lib a : a.cpp cool_lib/<shared>false : <shared>true ;

3. Introduce another feature:

lib a : a.cpp cool_lib : <shared>true <shared-dependencies>false ;

The third approach saves typing. But you get another problem:
If <shared-dependencies> affect how you link dependencies and <shared>
affects how targets are built, you need to make those features consistent.

Imagine that there's another lib that "a" uses: cool_lib2, which is
build from sources. If you want to link it statically, you have to
build it statically, for the value of <shared> for it my be computed
from the value of <shared-dependencies>... That would be rather tricky,
and I don't know what it gives us.

>>I view the current "shared" as saying: "use shared linking whenever possible".
>>Of course, if you want to use shared linking for exe, you'd have to use
>>shared linking for dependencies that are libraries. 
> 
> 
> What about dependencies of those libraries?

By default, <shared> is propagated to those libraries too. But they can
make a choice for themself.

>>So, <shared> is propagated. If you introduce another feature, then I
>>cannot say <shared>true on a single exe and have all dependency libs
>>built as shared too.
> 
> 
> I think it's important to be able to specify shared linking with one
> broad stroke, but I'm not sure it should be propagated more than one
> level through the (abstract) dependency graph.

What problems do you see in propagating them all the way? Because I see a 
couple of problems with doing otherwise:

1. We don't have any "broad stroke" approach. Even properties
in build request (from command line) apply only to
directly requested target, as we've discussed and agreed before.

2. Say I have two executable. One must link everything statically,
and another dynamically. With your approach, I can affect only
their direct dependencies.

- Volodya