From: David Abrahams (dave_at_[hidden])
Date: 2002-11-27 00:56:14
Rene Rivera <grafik666_at_[hidden]> writes:
> [2002-11-26] David Abrahams wrote:
>>Hmm. Isn't it true that you can link statically or dynamically to the
>>same .so on unix?
> Not AFAIK. You can link to a static(*.a) or dynamic(*.so) version. And
> additionally to specific numbered versions.
Oh, OK. I thought I just learned this. I could've sworn this was what
Markus was talking about with find-library-static. But I guess that
just finds libxxx.a or libxxx.so... so I guess I'll un-learn it now
> ...I think the idea of reducing the number of ways to specify a library is
> good. But I think the "system-lib" UI is not enough of a reduction.
> A rather more flexible and cohesive solution would be to incorporate
> the various instances of a library into the "lib" target.
Yes, I had the same thought.
> Here are the various ones I can think of, and how they might be
> 1. Locally built library:
> lib test : test.cpp ;
> 2. System available library, OS default linking:
> lib zlib : z : <system>true ;
> 3. System available library, static linking:
> lib zlib : z : <system>true <shared>false ;
What about a library available in both static and dynamic forms?
> 4. Externally available library, on a given location:
> lib zlib : z : <search>/usr/local/lib ;
Why not just:
lib zlib : /usr/local/lib/z ;
in that case?
> 5. System library, a specific version:
> lib zlib : z : <system>true <version>1
> And you can extrapolate all the various combinations from that. But
> the relevant features are:
> * <system> : true = Search standard locations and names, uses
> the source as the base name (above "z" would look for libz.so,
> libz.a, etc), false = The default, external or internal library.
false needs more explanation
> * <search> : Present = Search for non-standard locations but
> standard names using the source as the base name. One could specify
> more than one, and different ones depending on the toolset and/or
> * <version> : For internal libraries this does the soname procedures.
> For external libraries, links to the specific version of the library (above
> it would mean linking to "libz.so.1").
> With this approach it would be possible to support the possibility of having
> a library which can be both internally built or externally linked. The
> previously mentioned example was expat, which is normally included in the
> system in Linux, but not in Windows. For example:
> lib expat : expat : <system>true ;
> lib expat : source1.c source2.c ;
> exe test : main.cpp <library>expat/<system>true : <os>LINUX ;
> exe test : main.cpp <library>expat : <os>NT ;
> Of course that brings up the idea of having a feature to identify/select the
Yup. And we'll eventually need to deal with both host and target ;-/
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk