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-29 21:20:38

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

Comment(by 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 ? 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.
 > 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 (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.

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