Re: [Discuss-gnuradio] static libpython3.2.a issue while building gnuradio-core from CVS

[Stephane Fillod]

On Tue, Jun 21, 2005 at 07:08:06AM -0700, Mark S Petrovic wrote:
> I've deduced that there are things known about this issue, or a related
> issue, as I saw similar discussion here
> 
> http://lists.gnu.org/archive/html/discuss-gnuradio/2005-05/msg00148.html

This thread was more a libtool issue specific to MacOS X, where
libtool dropped the dependency against libpython when linking 
_gnuradio_swig_python.so.


[...]
> 2.  Python 2.3.5 built from source with --enable-shared and linked with
> -export-dynamic produces the following libraries
> 
> $ find /usr/lib -name libpython\* |xargs ls -l
> lrwxrwxrwx  1 root root      19 Jun 20 13:06 /usr/lib/libpython2.3.so -> 
> libpython2.3.so.1.0
> -r-xr-xr-x  1 root root  944568 Jun 20 13:06 /usr/lib/libpython2.3.so.1.0
> -rw-r--r--  1 root root 1479196 Jun 20 13:06 
> /usr/lib/python2.3/config/libpython2.3.a

what outputs "ldd /usr/lib/libpython2.3.so.1.0" ?

> 3.  via the invocation of "buildit" on gnuradio-core/, we get
> 
> ./bootstrap && ./configure --enable-maintainer-mode
> 
> which drives the execution of gr-build/gnuradio-core/config/gr_python.m4.
> 
> gr_python.m4 has in its PYTHON_DEVEL macro (see in gr_python.m4 "# Check for 
> Python
> headers usability") a loop that searches for libpython$PYTHON_VERSION.*.  The 
> loop list
> 
> for i in "$python_path/lib/python$PYTHON_VERSION/" 
> "$python_path/lib/python$PYTHON_VERSION/config/"  "$python_pat
> h/lib/python/config/" "$python_path/lib/python/" "$python_path/" 
> "$python_path/libs"
> 
> is ordered in such a way that /usr/lib/python2.3/config/libpython2.3.a
> is found before /usr/lib/libpython2.3.so.
> 
> As a result, the python dev lib test program as seen in 
> gnuradio-core/config.log
> 
> gcc -o conftest -g -O2 -Wall  -I/usr/include/python2.3  conftest.c  
> -L/usr/lib/python2.3/config -lpython2
> .3  -lpthread -ldl  -lutil >&5

So the loop list has to be tweaked. Then someone else stands up, the
new order breaks things on his system, and we're caught in a loop hole :-)
Maybe a configure option could solve this?

> does not succeed in linking because libpython2.3.a has unresolved math
> symbols.  For example, from config.log
> 
> /usr/lib/python2.3/config/libpython2.3.a(complexobject.o)(.text+0x2fe): In 
> function `_Py_c_pow':
> : undefined reference to `hypot'

Static library(archive) don't have dependency against libm.

Anyway, it's not going to work. In order to build the swig
wrappers, all the dependent libraries must be shared objects.

> 
> where
> 
> $ nm /usr/lib/python2.3/config/libpython2.3.a |grep hypot
>          U hypot
> 
> 4.  From my narrow perspective, I can "fix" this problem by moving
> "$python_path/" to the front of the "for" loop in gr_python.m4, such
> that /usr/lib/libpython2.3.so is found before the static lib version
> /usr/lib/python2.3/config/libpython2.3.a.  Doing so allows the test
> program to link to the .so version of the library, which results in a
> successful linking of the test program.
> 
> Or, one can fix by linking the test program to libm, but that doesn't
> sound right.

Fix the root cause  (actually, the one I messed up :*).

-- 
Stephane