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

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2007-03-20 13:07:54

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" <ghost_at_[hidden]>
To: <boost-build_at_[hidden]>
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
>
>