Re: [Discuss-gnuradio] Build from CVS fails, tarball succeeds, at _gnuradio_swig_python.la

[Eric Blossom]

On Fri, May 13, 2005 at 05:49:16PM -0700, Jonathan Jacky wrote:
>
> I've succesfully built gnuradio-core-2.5 from the tarball.
> I tried building from CVS for the first time today and failed. 
> In particular, make fails at the command to create _gnuradio_swig_python.la
> 
> I'm using Mac OS X 10.3.8 "Panther" with autoconf 2.59, automake 1.9.4,
> pkg-config 0.15.0, libtool 1.5.2, and swig 1.3.24.
> 
> I built gnuradio-core-2.5 from the tarball again and compared all the
> messages to the build from CVS to identify the point where they
> differ.  Here's what I found.
> 
> Then they differ.  Building from the 2.5 tarball:
> 
> /bin/sh ../../../libtool ...  -o _gnuradio_swig_python.la
> ... -avoid-version gnuradio_swig_python.lo ...
> 
> Building from CVS, there is one more flag, -no-undefined:
> 
> /bin/sh ../../../libtool ... -o _gnuradio_swig_python.la 
> ... -avoid-version -no-undefined gnuradio_swig_python.lo ...
> 
> And then, building _gnuradio_swig_python.la from the 2.5 tarball succeeds:
> 
> g++ -Wl,-bind_at_load -flat_namespace -undefined suppress
> -o .libs/_gnuradio_swig_python.dylib
> -bundle  .libs/gnuradio_swig_python.o
> -L/opt/local/lib ../../../src/lib/.libs/libgnuradio-core.dylib
> /opt/local/lib/libcppunit.dylib -lstdc++
> creating _gnuradio_swig_python.la
> ...
> 
> But building it from CVS it fails, and the command that fails is different:
> 
> g++ -Wl,-bind_at_load
> -o .libs/_gnuradio_swig_python.so
> -bundle  .libs/gnuradio_swig_python.o /opt/local/lib/libcppunit.dylib 
> -L/opt/local/lib ../../../src/lib/.libs/libgnuradio-core.dylib
> -lstdc++
> ld: Undefined symbols:
> _PyArg_ParseTuple
> _PyCFunction_Type
> ... (many many more undefined symbols)
> make[5]: *** [_gnuradio_swig_python.la] Error 1
> 
> (I wrapped the lines above so they'd fit, and to ease comparison)
> 
> I find that all the undefined symbols are there in
>  gnuradio-core/src/lib/swig/.libs/gnuradio_swig_python.o
> as revealed by
>  % nm gnuradio_swig_python.o | grep _Py

I suspect that they are undefined in gnuradio_swig_python.o
When you nm | grep do the lines start with a "T" or a "U" ?

I think what you are seeing is an unintended consequence of changes we
made to GNU Radio to get it to build under MinGW and Cygwin.  Please
bear with me while we find a soln that works for all systems.

Please try removing the -no-undefined flag in
gnuradio-core/src/lib/swig/Makefile.am and let me know it that fixes
the problem.

What I've noticed is that on some systems, there is a libpython<X.Y>
library that contains the symbols that you are seeing as undefined.
The new autoconf code apparently didn't find the library on your
system.  It could be trying the wrong name, path, etc.

On Fedora Core 2, the python program is linked using the
--export-dynamic option which makes all of it's globals available to
shared libraries that are subsequently loaded.  Most other systems
I've seen, including FC3, have libpython<X.Y> and the python
executable is a very tiny program (2KB) that links against the
library.

On OS/X, is there a program that will tell you what shared libraries a
program depends on / is linked against?  On linux it's called "ldd"

That might give us a way to locate the missing library. 

Eric