Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-24 17:17:21


Vladimir Prus <ghost_at_[hidden]> writes:

> I'm seeing something strange. When linking Boost.Python, the command line is:
>
> "g++" -g ..... -L"/usr/lib/python2.3/config"
>
> however, there's no -lpython2.3 there, and the following output:
>
> readelf
> -d ../../../bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/libboost_python_debug.so
>
> Dynamic segment at offset 0xba240 contains 24 entries:
> Tag Type Name/Value
> 0x00000001 (NEEDED) Shared library: [libstdc++.so.5]
> 0x00000001 (NEEDED) Shared library: [libm.so.6]
> 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
> 0x00000001 (NEEDED) Shared library: [libc.so.6]
> 0x0000000e (SONAME) Library soname:
> [libboost_python_debug.so.1.32.0]
>
> say Boost.Python does not link to Python. This looks OK, because when
> extension is loaded, symbols in Boost.Python will be resolved against
> interpreter binary and the -L option in the command line is accidental.
>
> But
> 1. Is my understanding correct?

Yes.

> 2. Is linking Boost.Python agaist Python bad for some reason?

On Unix: yes, for the same reason that you don't link any Python
extension modules against libpythonXX. You want to pick up the
symbols in the interpreter, not those in libpythonXX, and if both are
present at the same time you'll get dynamic load conflicts.

> Does it matter?

IIRC, yes.

> The only case where it matter is if one dynamically loads
> Boost.Python with the RTLD_NOW flag and before loading Python
> interpreter -- which does not seem very realistic.

Did you actually try it?

That was how I tried to link on UNIX when I was getting started, and
it caused me no end of problems.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
 

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