Python's "alternatives" issue

I've looked into Python issues that occur for Martin. It's
pure
linux, no cygwin involved. Locally, I can reproduce them
with the following user-config.jam:

	using gcc ;
	using gcc : 4.1.0 ;
	using gcc : 4.1.2 ;

	using python : 2.4 : /usr : : ;
	using python : 2.4 : /usr : : : <toolset>gcc
<toolset-gcc:version>4.1.0 ;
	using python : 2.4 : /usr : : : <toolset>gcc
<toolset-gcc:version>4.1.2 ;

The original intention, as I understand it, is to be able to
specify custom version
of python for a particular gcc version -- in the real
example the paths
to python are different.

With that, and some local patches to improve diagnostics,
running "bjam -n" in libs/python/test, I get:

  error: No best alternative for /python-2.4
    next alternative: required properties: (empty)
             full requirements:  <name>python2.4
<toolset>msvc,<runtime-link>shared:<threading
>multi
        matched
    next alternative: required properties: (empty)
             full requirements:  <name>python2.4
<toolset>msvc,<runtime-link>shared:<threading
>multi
        matched

which is no wonder, in fact. Looking at
python.jam:declare-libpython-target, I see
that it does not take any parameters for condition, and
therefore declares identical
targets if version and target-os are the same. I see the
following arrangment:

        local libpython-target-name = [
declare-libpython-target $(version) : $(target-os) :
$(condition) ] ;
        alias python
          : $(system-libs) 
          : $(condition)
          :
          : <include>$(includes)
<library-path>$(libraries)
<library>$(libpython-target-name)
          ;


Whereas the 'python' target is declared with 'condition',
'condition' is not passed
to declare-libpython-target, which leads to this problem. I
don't quite understand
why this two-stage scheme is used, and there's no comment to
explain it.

There are two possible solutions:

1. Pass 'condition' to declare-libpython-target
2. Kill declare-libpython-target, add proper <name>
property to 'python' target
directly.

Dave, can you clarify what's the purpose of 
'declare-libpython-target'.

- Volodya


	

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Mon Mar 19 2007, Vladimir Prus <ghost-AT-cs.msu.su>
wrote:

> running "bjam -n" in libs/python/test, I
get:
>
>   error: No best alternative for /python-2.4
>     next alternative: required properties: (empty)
>              full requirements:  <name>python2.4
<toolset>msvc,<runtime-link>shared:<threading
>multi
>         matched
>     next alternative: required properties: (empty)
>              full requirements:  <name>python2.4
<toolset>msvc,<runtime-link>shared:<threading
>multi
>         matched
>
> which is no wonder, in fact. Looking at
> python.jam:declare-libpython-target, I see that it does
not take any
> parameters for condition,

I don't know what you mean exactly by "parameters for
condition," but
the condition is passed to declare-libpython-target in its
"requirements" parameter.

> and therefore declares identical targets
> if version and target-os are the same. I see the
following
> arrangment:
>
>       local libpython-target-name = [
declare-libpython-target $(version) : $(target-os) :
$(condition) ] ;

There's the condition, in the last argument to
declare-libpython-target.  What am I missing?

I note that you also don't seem to be working with the
latest code, as
the variable passed as the last argument is now called
target-requirements.

>         alias python
>           : $(system-libs) 
>           : $(condition)
>           :
>           : <include>$(includes)
<library-path>$(libraries)
<library>$(libpython-target-name)
>           ;
>
>
> Whereas the 'python' target is declared with
'condition', 'condition' is not passed
> to declare-libpython-target, 

??  I'm really confused.  I don't see how you can say that.

> which leads to this problem. I don't quite understand
why this
> two-stage scheme is used, and there's no comment to
explain it.

What two-stage scheme?

> There are two possible solutions:
>
> 1. Pass 'condition' to declare-libpython-target

Already doing that.

> 2. Kill declare-libpython-target, add proper
<name> property to
> 'python' target directly.

As far as I can tell, declare-libpython-target _is_ adding a
proper
<name> property... to the libpython target.  But maybe
I'm missing
something.

> 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.

* I went looking for information about what to use instead,
and I
  found this posting:
  http://thread.gmane.org/gmane.comp.lib.boost
.build/13689/focus=13693
  Where you say

    The <find-library-*> feature are not for users,
which should use
    'lib' target anyway.

So I figured the right thing to do would be to define a
"lib" target
for the python library.

So maybe that's what you mean by "two-stage." 
Well, in general
libpython can be used in two different ways (extending and
embedding),
so it seems rational to make it a separate target.  I can
see that
it's being directly used only by that one alias
("python"), so maybe
there's a way to eliminate it as a separate target, but that
way isn't
obvious to me, and it's also not clear why that should
change anything
about the problem Martin is seeing.  As I wrote to you
semi-privately,
I'm up against the limitations of my understanding of
Boost.Build now.

Incidentally, I also notice that I'm adding libpython by
using the
<library> feature instead of just listing it in the
sources, and I
don't know why.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Tuesday 20 March 2007 02:16, David Abrahams wrote:

> I note that you also don't seem to be working with the
latest code, as
> the variable passed as the last argument is now called
> target-requirements.

Doh, CVS decided to keep me on bbv2python branch! I'm
getting
the other error, that I'm investigating.


> > which leads to this problem. I don't quite
understand why this
> > two-stage scheme is used, and there's no comment
to explain it.
> 
> What two-stage scheme?

'python' target that depends on some other python target
having
version in target name.

> > 2. Kill declare-libpython-target, add proper
<name> property to
> > 'python' target directly.
> 
> As far as I can tell, declare-libpython-target _is_
adding a proper
> <name> property... to the libpython target.  But
maybe I'm missing
> something.
> 
> > 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.

> * I went looking for information about what to use
instead, and I
>   found this posting:
>   http://thread.gmane.org/gmane.comp.lib.boost
.build/13689/focus=13693
>   Where you say
> 
>     The <find-library-*> feature are not for
users, which should use
>     'lib' target anyway.

But it's not user code. But anyway, that's not what I find
important.

> So I figured the right thing to do would be to define a
"lib" target
> for the python library.
> 
> So maybe that's what you mean by "two-stage."
 Well, in general
> libpython can be used in two different ways (extending
and embedding),
> so it seems rational to make it a separate target.  I
can see that
> it's being directly used only by that one alias
("python"), so maybe
> there's a way to eliminate it as a separate target, 

Add <name>XXXX to the 'python' target, and change its
type from alias
to lib? I'm gonna try it while I'm on it.

> but that way isn't 
> obvious to me, and it's also not clear why that should
change anything
> about the problem Martin is seeing.  

Such a change is only to simplify code.

> As I wrote to you semi-privately, 
> I'm up against the limitations of my understanding of
Boost.Build now.
> 
> Incidentally, I also notice that I'm adding libpython
by using the
> <library> feature instead of just listing it in
the sources, and I
> don't know why.

Okay, I'll see if that can be made simpler.

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

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.

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.

-- Noel


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

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-
>>>>> 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.

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.

-- Noel


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Tue Mar 20 2007, Vladimir Prus <ghost-AT-cs.msu.su>
wrote:

> 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.

I'm not sure that matters.  If we tell users that they
should use
"find-xxx-library" when they _know_ there's an xxx
library present and
they want to be sure to use that one and not some yyy flavor
of the
same library, either behavior is sufficient.  We can even
say that
when an xxx library isn't present, the behavior is
unspecified.

The behaviors of the GCC flags are obviously useful to some
people or
they wouldn't exist, and I don't see why they shouldn't be
supported.

>> 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.

Yeah, but so what?  You can ask for that flavour and
get-it-if-it's-available.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Tue Mar 20 2007, Vladimir Prus <ghost-AT-cs.msu.su>
wrote:

> On Tuesday 20 March 2007 02:16, David Abrahams wrote:
>
>> I note that you also don't seem to be working with
the latest code, as
>> the variable passed as the last argument is now
called
>> target-requirements.
>
> Doh, CVS decided to keep me on bbv2python branch! I'm
getting
> the other error, that I'm investigating.

OK, thanks.

>> > which leads to this problem. I don't quite
understand why this
>> > two-stage scheme is used, and there's no
comment to explain it.
>> 
>> What two-stage scheme?
>
> 'python' target that depends on some other python
target having
> version in target name.

I also realize that sticking the version in the target name
is
completely unnecessary.  

>> > 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.

I don't think that makes sense.  For example, on cygwin the
python dll
can be found in the same directory as its import library. 
Does it
make sense to entirely give up control over which one we
link to?

>> * I went looking for information about what to use
instead, and I
>>   found this posting:
>>   http://thread.gmane.org/gmane.comp.lib.boost
.build/13689/focus=13693
>>   Where you say
>> 
>>     The <find-library-*> feature are not for
users, which should use
>>     'lib' target anyway.
>
> But it's not user code. But anyway, that's not what I
find important.
>
>> So I figured the right thing to do would be to
define a "lib" target
>> for the python library.
>> 
>> So maybe that's what you mean by
"two-stage."  Well, in general
>> libpython can be used in two different ways
(extending and embedding),
>> so it seems rational to make it a separate target. 
I can see that
>> it's being directly used only by that one alias
("python"), so maybe
>> there's a way to eliminate it as a separate target,

>
> Add <name>XXXX to the 'python' target, and change
its type from alias
> to lib? I'm gonna try it while I'm on it.
>
>> but that way isn't 
>> obvious to me, and it's also not clear why that
should change anything
>> about the problem Martin is seeing.  
>
> Such a change is only to simplify code.

OK, that's fine.  I hope it will help you solve the real
mysteries.  I
still like the idea of having a libpython target that's
symmetric with
rt, dl, et. al., but that's just an aesthetic
consideration.

>> As I wrote to you semi-privately, 
>> I'm up against the limitations of my understanding
of Boost.Build now.
>> 
>> Incidentally, I also notice that I'm adding
libpython by using the
>> <library> feature instead of just listing it
in the sources, and I
>> don't know why.
>
> Okay, I'll see if that can be made simpler.

Thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:
> [...] 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.
[...]
>
> 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.

Both Tru64 and HP-UX allow requesting specific flavour of a
specific
library. From the ld manpage on both platforms:

Tru64
------
  The library search can be restricted to shared libraries
by the -noarchive
  option or to archive libraries by the -noso option. The
-so_archive option
  removes either of these search restrictions.

  -noarchive
      Require -l references to resolve to shared objects.
Normally, if the
      shared object as specified by the -l is not found, the
linker attempts
      to find the corresponding archive to resolve undefined
symbols. This
      option disallows using those archives. Note that this
option is posi-
      tion sensitive and can be used more than once on a
command line. It
      affects only those options that follow it, and it is
turned off by the
      next occurrence of a -noso or -so_archive option.

  -noso
      Require -l references to resolve to archive libraries.
Note that this
      option is position sensitive and can be used more than
once on a com-
      mand line. It affects only those options that follow
it, and it is
      turned off by the next occurrence of a -noarchive or
-so_archive
      option.

  -so_archive
      Turn off either the -noarchive or -noso options
allowing -l references
      to resolve to either shared objects or archive
libraries in shared or
      call_shared links. This option is position sensitive.

HP-UX
--------
           -a search  Specify whether shared or archive
libraries are
                          searched with the -l option.  The
value of search
                          should be one of archive, shared,
archive_shared,
                          shared_archive, or default.  This
option can
                          appear more than once,
interspersed among -l
                          options, to control the searching
for each
                          library.  The default is to use
the shared version
                          of a library if one is available,
or the archive
                          version if not.

                          If either archive or shared is
active, only the
                          specified library type is
accepted.

                          If archive_shared is active, the
archive form is
                          preferred, but the shared form is
allowed.

                          If shared_archive is active, the
shared form is
                          preferred but the archive form is
allowed.

----- Original Message ----- 
From: "Vladimir Prus" <ghostcs.msu.su>
To: <boost-buildlists.boost.org>
Sent: Tuesday, March 20, 2007 3:40 AM
Subject: Re: [Boost-build] Python's "alternatives"
issue


> 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
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
> 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build