Re: [Boost-build] Python's "alternatives" issue

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-03-20 03:40:03

On Tuesday 20 March 2007 10:34, K. Noel Belcourt wrote:
> Hi Volodya,
> 
> On Mar 20, 2007, at 1:13 AM, Vladimir Prus wrote:
> 
> > On Tuesday 20 March 2007 02:16, David Abrahams wrote:
> >>> Dave, can you clarify what's the purpose of  'declare-libpython- 
> >>> target'.
> >>
> >> Well, the body of python.configure was (and still is) too long, so I
> >> tried to factor out as many logically coherent units as possible, and
> >> this was one of them.  If you're asking why there's an invocation of
> >> the "lib" rule and a separately declared libpython target at all, the
> >> story goes like this:
> >>
> >> * The old code (see HEAD) used <find-shared-library> in the python
> >>   alias to refer to the python library instead of a "lib" target.
> >>
> >> * <find-shared-library> is really wrong, because libpython isn't
> >>   necessarily a shared library at all.
> >
> > That's in theory, in practice we might rename 'find-shared-library' to
> > 'find-library' since no toolchain allows to accurately request only  
> > shared or
> > static library.
> 
> What precisely does this mean (allows to accurately request only  
> shared or static library)?  This sounds like you mean no toolset  
> permits only static or shared?  We have several toolsets that permit  
> only static, in one case, and only shared, in a completely different  
> case.

I mean that I personally don't know any toolset that can say: "I want library
X to be shared/static, if such flavour is not found, bail out". In fact, I only
know of gcc that tries to support that -- but its "-shared" means "prefer shared libs",
while its "-static" means "link only to static", so they are not symmetric.

> For example, on the Cray xt3, we require <runtime-link-static> which  
> requires <link>static which excludes <find-shared-library> as a  
> matching property.  Other toolsets requires only <runtime-link- 
> shared> since they all use different version of the Myrinet (MPI)  
> libraries and a statically bound executable won't run on a system  
> unless it has the same internal Myrinet version number (that's why we  
> have to ship only <runtime-link-shared> for external release even  
> though we support static linking internally.
> 
> Not sure if this is the same case but we definitely have cases where  
> the OS (or library) only supports static or shared, not both.

I'm saying that if OS allows both static and shared, I don't know any way
to ask for a specific flavour of a specific library and always get it.

- Volodya