Re: [jamboost] runtime-link

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-04 11:58:54

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> 
> 
>>I'm in process of implementing new system libraries interface and
>>have a couple of question on runtime-link feature.
>>
>>1. What should it do? Will it affect the way toolset runtime is linked,
>> or default linking for all system libraries.
> 
> 
> The intention was just to affect the runtime. Of course, there's a
> question of whether I chose the right feature to implement in the
> first place.

I can see several possible scenarious:

1. Everything's shared. That can be used both for development
and for version for customer, provided you know how to set
correct paths for dynamic loader

2. Every internal library is static. System libraries and C runtime
is dynamic. Usefull when you make assumption about system libraries
but don't want to deal with runtime link paths.

3. Everything's static. Usefull when you want to create a binary that
will work on a different system (i.e. with older C runtime).

I'm not sure it's usefull to link statically to all system libraries
except for C runtime -- I'd like to see the case, if it exists.
Seems that if a specific system library is causing problems,
you can link statically only *that library*, explicitly.

Maybe, we need a feature that would affect all system libraries, including
C runtime.

Unfortunately, such feature would erase similarlity between system and 
internal libraries. If "a" is internal and "b" is system, and I specifically
want static linking for both, I'd have to write.

exe main : a/<shared>false <b>/<system-shared>false ;

and that's ugly. Any bright ideas what to do with it?

OK, I'll try to think about it more, when I'm away from computer -- this
sometimes gives good results.

> I don't think it's possible, in general, to do this sort of thing for
> "all system libraries", is it? I'm thinking of Windows, where most
> libraries are explcitly either static or dynamic. I might be mistaken
> about that, though.

You mean that you should place either ordinary lib or import lib to
the linker's command line?

Boost.Build can hide that difference:

system-lib zlib : : <file>zlib.lib <shared>false ;
system-lib zlib : : <file>zlib_import.lib <shared>true ;

>>2. Why it's symmetric in V1? I'm using V2 quite extensively now
>> (though on small projects), and I got accustomed to paths like
>>
>> bin/gcc/debug/example1
>>
>> I certainly don't want "runtime-link-dynamic" to be added to this
>> nice path!
>>
>>Hope to hear comment on this.
> 
> 
> It just seemed wrong to have one be "the default" w.r.t. paths. Static
> and dynamic runtime linking seemed, at the time, to have equal weight.

This depends on your point of view. On Linux, static linking to runtime
is extremely rare.

> Maybe symmetric features should go away in v2, I don't know.

Neither do I.

- Volodya