[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] static libpython3.2.a issue while building gnurad
From: |
Stephane Fillod |
Subject: |
Re: [Discuss-gnuradio] static libpython3.2.a issue while building gnuradio-core from CVS |
Date: |
Tue, 21 Jun 2005 21:06:06 +0200 |
User-agent: |
Mutt/1.5.8i |
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