From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2007-03-20 03:58:04
On Mar 20, 2007, at 1:40 AM, Vladimir Prus wrote:
> On Tuesday 20 March 2007 10:34, K. Noel Belcourt wrote:
>> 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-
>>>> 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
> 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
True. We have this problem with numerous toolsets.
>> 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.
Okay, this is consistent with my experience.
Thanks for the clarification.
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