discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] static libpython3.2.a issue while building gnuradio-c


From: Mark S Petrovic
Subject: [Discuss-gnuradio] static libpython3.2.a issue while building gnuradio-core from CVS
Date: Tue, 21 Jun 2005 07:08:06 -0700
User-agent: Mutt/1.5.6i

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

However, I provide what I believe may be related detail and
reproducibility that may be helpful.

In the course of building (not running) gnuradio-core from CVS, I
encounter an unresolved symbol issue related to a static libpython
library in Python 2.3.5.

1. My environment:

Gentoo Linux 2005.0

Linux cq 2.6.11-gentoo-r11 #2 Thu Jun 16 17:29:09 PDT 2005 i686 Pentium III 
(Coppermine) GenuineIntel GNU/Linux
gcc             v3.4.4
autoconf        v2.59
automake        v1.9.5
libtool         v1.5.16
swig            v1.3.25
python          v2.3.5
pkg-config      v0.15.0

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

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

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'

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.

Mark




reply via email to

[Prev in Thread] Current Thread [Next in Thread]