GNU Radio release 3.3.0-rc0 available for testing

jconley · May 13, 2010, 5:46am

GNU Radio release 3.3.0-rc0 is available for testing:

http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc0.tar.gz
http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc0.tar.gz

This is the first release candidate for the 3.3 release series.

This is a straight tarball release from the current git master, and
there is expected to be at least one more release candidate with both
merges of new functionality and bug fixes before 3.3.0 makes it out
the door. There are not yet binary installation packages for
Debian/Ubuntu/Fedora.

Johnathan C.
Corgan Enterprises LLC

jconley · May 14, 2010, 3:12am

Johnathan C. wrote:

GNU Radio release 3.3.0-rc0 is available for testing:

http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc0.tar.gz
http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc0.tar.gz

This is the first release candidate for the 3.3 release series.

This builds and runs on MinGW/MSYS except that it has the same problem
as
the 3.3git-594 tarball: The supplied version of ltmain.sh does not
handle
interlibrary dependencies on Windows. I have attached a diff file
showing
the slight differences between the ltmain.sh in the tarball (2.2.6b
Debian-2.2.6b-2ubuntu1, which fails) and the ltmain.sh downloaded from
packages.debian.org (plain 2.26b). It looks like it was broken in
Ubuntu
2.2.6a-3 (change log says “Don’t pull in depedency libs when linking a
binary”). GNU Radio builds ok if I run ./bootstrap locally.

It would be nice if we could ship a tarball with a ltmain.sh that works
on
Windows.

– Don W.

P.S.: I have brought the MinGW install page on the wiki up to date (I
hope
to add instructions for git soon).

jconley · May 14, 2010, 7:10pm

Johnathan C. wrote:

GNU Radio release 3.3.0-rc0 is available for testing:

http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc0.tar.gz

Builds smoothly on Cygwin after replacing ltmain.sh in tarball with
ltmain.sh from git repository.

– Don W.

jconley · May 14, 2010, 4:27am

On Thu, May 13, 2010 at 18:10, Don W. [email protected] wrote:

I have attached a diff file showing
the slight differences between the ltmain.sh in the tarball
[…]
It would be nice if we could ship a tarball with a ltmain.sh that works on
Windows.

This has been applied. Rather, ltmain.sh from libtool 2.2.6b has been
added to the repository. Previously, this was not under version
control, and we relied on the bootstrap process to copy it over from
the installed libtool on whatever system was being used. Now with it
in the repository, the bootstrap process will defer to our copy.

Johnathan

jconley · May 14, 2010, 7:51pm

On Fri, May 14, 2010 at 10:06, Don W. [email protected] wrote:

Builds smoothly on Cygwin after replacing ltmain.sh in tarball with
ltmain.sh from git repository.

Thanks. I’ve added it to the tarball distribution (and will show up
in rc1 tarball.)

Johnathan

jconley · May 16, 2010, 4:57pm

On Fri, May 14, 2010 at 10:06, Don W. [email protected] wrote:

http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc0.tar.gz

Builds smoothly on Cygwin after replacing ltmain.sh in tarball with
ltmain.sh from git repository.

Unfortunately, putting ltmain.sh in the repository creates more
problems than it solves. I’ve just reverted the two commits.

I can address this in the tarball only when it gets created for rc1.

Johnathan

jconley · May 18, 2010, 1:44am

The standard “configure; make; make check; make install; make
uninstall” works just fine on OSX 10.5.8. “make distcheck” fails in
gr-qtgui before ‘configure’ even gets executed, I suppose because this
component doesn’t compile easily on OSX to begin with (so, I don’t use
it) – either way, might be worth disabling whatever parts those are
in that Makefile.am, if the component isn’t active to begin with. - MLD

jconley · May 18, 2010, 4:14am

On Mon, May 17, 2010 at 7:42 PM, Michael D. [email protected]
wrote:

The standard “configure; make; make check; make install; make uninstall”
works just fine on OSX 10.5.8. “make distcheck” fails in gr-qtgui before
‘configure’ even gets executed, I suppose because this component doesn’t
compile easily on OSX to begin with (so, I don’t use it) – either way,
might be worth disabling whatever parts those are in that Makefile.am, if
the component isn’t active to begin with. - MLD

Interesting. I think you’re right that it shouldn’t effect a
distcheck. I’ll try to look into it.

If I had access to an OSX box, I’d see about getting qtgui to work
better on it.

Tom

jconley · May 18, 2010, 8:12pm

On May 17, 2010, at 8:11 PM, Tom R. wrote:

If I had access to an OSX box, I’d see about getting qtgui to work
better on it.

Well … IIRC, the issue is that there is no standard install of Qt on
OSX; one must do it by hand from source or use MacPorts / Fink /
whatever. At least for MacPorts, Qt is installed into $prefix/libexec/
qt4-mac , but then symlinks are dropped into $prefix/lib/pkgconfig
with the hope that pkg-config is provided with the correct names to
determine where Qt is installed. The Qt .pc files are:

Qt3Support_debug.pc, QtAssistant_debug.pc, QtCLucene_debug.pc,
QtCore_debug.pc, QtDBus_debug.pc, QtDesignerComponents_debug.pc,
QtDesigner_debug.pc, QtGui_debug.pc, QtHelp_debug.pc,
QtMultimedia_debug.pc, QtNetwork_debug.pc, QtOpenGL_debug.pc,
QtScriptTools_debug.pc, QtScript_debug.pc, QtSql_debug.pc,
QtSvg_debug.pc, QtTest_debug.pc, QtUiTools_debug.pc,
QtWebKit_debug.pc, QtXmlPatterns_debug.pc, QtXml_debug.pc,
phonon_debug.pc

though the non “_debug” versions are in $prefix/libexec/qt4-mac/lib/
pkgconfig . I don’t know why they do it this way, but I’ll look to
see if there are any tickets open to change this behavior.

I don’t remember how GNU Radio checks for Qt; maybe you can look into
that & add in the debug variants & make sure a non-standard install
location would work? I’d love to use Qt with GNU Radio on OSX, so I’m
happy to collaborate with you on the side to get this working. - MLD

jconley · May 14, 2010, 11:40pm

On 14 May 2010 19:26, Johnathan C. [email protected]
wrote:

On Fri, May 14, 2010 at 10:06, Don W. [email protected] wrote:

Builds smoothly on Cygwin after replacing ltmain.sh in tarball with
ltmain.sh from git repository.

Thanks. I’ve added it to the tarball distribution (and will show up
in rc1 tarball.)

Now the code from git won’t build on Ubuntu 9.10 because it has libtool
2.2.6:

libtool: Version mismatch error. This is libtool 2.2.6b, but the
libtool: definition of this LT_INIT comes from libtool 2.2.6.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b
libtool: and run autoconf again.

I deleted ltmain.sh ran bootstrap and configure again where after build
was OK.

On 10.04 it’s no problem because it also has llibtool 2.2.6b

Alex

jconley · May 20, 2010, 12:35am

On Wed, May 19, 2010 at 04:01:23PM +0200, Alexandru C. wrote:

Greetings,

I noticed a minor build issue that started to exist few months ago. If
configuring using --prefix=/somedir and somedir does not already
exist, then build will fail with the error:

Fixed in changeset 6f9093edd6d9 on master.

Thanks for pointing out the problem.

Eric

jconley · May 19, 2010, 4:03pm

Greetings,

I noticed a minor build issue that started to exist few months ago. If
configuring using --prefix=/somedir and somedir does not already
exist, then build will fail with the error:

make[5]: Entering directory
/home/alc/gnuradio/source/3.3git-rc0-26-g89440000/usrp/firmware/src/usrp2' test -fbasename 'eeprom_boot.a51’|| ln -s 'eeprom_boot.a51' . test -f ../common/basename 'eeprom_boot.a51’-o \ \! -fdirname 'eeprom_boot.a51’/../common/basename
'eeprom_boot.a51’\ || ln -sdirname
'eeprom_boot.a51’/../common/basename 'eeprom_boot.a51’../common/basename 'eeprom_boot.a51’asx8051 -plosgffbasename 'eeprom_boot.a51’sdcc -mmcs51 --no-xinit-opt -I../../../../usrp/firmware/include -I../../../../usrp/firmware/src/usrp2 -I../../../../usrp/firmware/src/common -I../../../../usrp/firmware/src/common -DHAVE_USRP2 \ -c -o eeprom_init.reltest -f ‘eeprom_init.c’ || echo
'./'eeprom_init.c test -fbasename '_startup.a51’|| ln -s '_startup.a51' . test -f ../common/basename '_startup.a51’-o \ \! -fdirname '_startup.a51’/../common/basename
'_startup.a51’\ || ln -sdirname ‘_startup.a51’/../common/basename
‘_startup.a51’../common/basename ‘_startup.a51’asx8051 -plosgffbasename ‘_startup.a51’sdcc -mmcs51 --no-xinit-opt --code-loc 0x0000 --code-size 0x1800 --xram-loc 0x1800 --xram-size 0x0800 -Wl '-b USBDESCSEG = 0xE000' -L ../../lib libfx2.lib -o eeprom_boot.ihx eeprom_boot.rel eeprom_init.rel _startup.rel /usr/bin/python ./../common/build_eeprom.py -p/opt/gnuradio/3.3git-rc0-26-g89440000 -r2 eeprom_boot.ihx > burn-usrp2-eeprom PREFIX dir (/opt/gnuradio/3.3git-rc0-26-g89440000), does not exist make[5]: *** [burn-usrp2-eeprom] Error 1 make[5]: Leaving directory/home/alc/gnuradio/source/3.3git-rc0-26-g89440000/usrp/firmware/src/usrp2’
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
/home/alc/gnuradio/source/3.3git-rc0-26-g89440000/usrp/firmware/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory/home/alc/gnuradio/source/3.3git-rc0-26-g89440000/usrp/firmware’
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
/home/alc/gnuradio/source/3.3git-rc0-26-g89440000/usrp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/alc/gnuradio/source/3.3git-rc0-26-g89440000’
make: *** [all] Error 2

Creating the target directory manually before executing “make” fixes
the problem but AFAIK this should not be necessary since “make
install” will create all the required directories.

I looked in the build_eeprom.py script but I can’t see why checking
that “prefix” exists at build time is required.

Alex