Re: [Boost-bugs] [Boost C++ Libraries] #2615: boost 1.37.0 does not link against libpython

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #2615: boost 1.37.0 does not link against libpython
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-12-30 03:14:49

#2615: boost 1.37.0 does not link against libpython
----------------------------------+-----------------------------------------
  Reporter:  fundawang_at_[hidden]  |       Owner:  dave          
      Type:  Bugs                 |      Status:  closed        
 Milestone:  Boost 1.38.0         |   Component:  Building Boost
   Version:  Boost 1.37.0         |    Severity:  Problem       
Resolution:  invalid              |    Keywords:                
----------------------------------+-----------------------------------------
Changes (by anonymous):

  * status:  reopened => closed
  * resolution:  => invalid

Comment:

 Replying to [comment:5 jhunold]:
 > > What does "direct linking" mean, precisely?
 > adding -lpython to the linker command line when linking
 libboost_python.so
 > > Will direct linking" against libpython.so force libpython.so to be
 loaded when the Python executable loads an extension module that uses
 libboost_python.so?
 > Yes, of course. Does this cause any problems ?

 Yes, of course.  It forces a dependency on libpython.so and increases the
 overall runtime image, aside from very likely causing duplicate copies of
 the code, and more worryingly, globals.

 > I've just dug out that I've patched python.jam to link extension modules
 against libpython.so due to a bug in the preview version of gold, the new
 ld replacement from Google which did not support undefined symbols at that
 time. Will attach the patch right now, although it seems not to be needed
 anymore with binutils 2.19. My (one and only experimental) module works
 fine with and without explicit linking to libpython.


 Can you pass the Boost.Python test suite?

 {{{
    cd libs/python/test
    bjam
 }}}

 > > What does the windows platform have to do with this?
 > Nothing directly. -no-undefined is just a tool to assist in cross-
 platform development. The usage is to spot unexported/undefined symbols
 when using gnu ld on unix platforms. Remember, gnu ld allows for symbols
 to be undefined at link time

 Believe me, I know

 > (this is used when linking libboost_python right now). msvc link.exe
 needs all symbols to be explicitly exported/imported for all libraries the
 current .dll depends on. So if you use gcc visibility and -no-undefined
 you are less likely to check out on windows and hit "missing" symbols due
 to forgotten "dllexport/-import" specifications." This is the way Qt goes
 and which I use to minimize broken builds on Windows because my main
 development platform is Linux.

 It's a nice technique, but it's not equivalent at all when it comes to
 Python because on Windows, python.exe uses the python shared library while
 on unix the python executable does not.

 Still willing to have you re-open the ticket if you still believe I'm
 wrong.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/2615#comment:6>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.