GNU Radio Release 3.0.3 Available


#1

GNU Radio Release 3.0.3 unofficial tarballs are now available:

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

These are the official release tarballs, but have not been signed or
uploaded yet to the official GNU Project mirror system.

This is a bug fix and very minor enhancement update to the stable
branch. All of the relevant bug fixes that have occurred on the main
development trunk have been back ported here. Details regarding the
release history may be found at:

http://gnuradio.org/trac/wiki/Release3.0Branch

A few notes:

  • For those using the digital packet modulator/demodulators, a long-time
    issue with stalled packet transfers has been corrected. A bug in the
    correlator was causing false sync in the middle of packets, corrupting
    their content.

  • Shared library linking cleanup, regression

Shared library linking has been cleaned up significantly in this
release. This ensures that the proper GNU Radio libraries in the build
tree are linked against and prevents conflicts with old or previously
installed versions of GNU Radio. However, this change also introduces a
functional regression relative to 3.0.2 and earlier. It is not possible
to build individual GNU Radio components completely in isolation;
rather, one must at least build the gnuradio-core component
simultaneously with any other component. This problem mainly impacts
packaging systems attempting to split GNU Radio into a package for each
component; most users are unaffected. The instructions at:

http://gnuradio.org/trac/wiki/BuildConfiguration

…remain unchanged.

  • There are many small updates to the build system for cross-platform
    compatibility. We are striving to ensure GNU Radio builds without
    change across GNU/Linux (various distributions), NetBSD, FreeBSD, Mac
    OS/X, and as a stretch goal, the Cygwin/MSYS environment under Win32.

Enjoy.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com


#2

Johnathan - I was away on travel while this was released, but now
that I’m back I checked this 3.0.3 release out on both Intel and PPC
OSX, and make, make check, make distcheck, etc… all work great.
Great work to all involved!

I’m -quite- stumped by the lack of functionality on PPC-OSX by the
trunk. The primary significant change that I can think of between
3.0.3 and trunk is the movement of omnithread from gnuradio-core to
its own library space (gromnithread) … correct me if I’m wrong in
this belief. Now that I’m back, I’m back to investigating this
issue … truly strange. - MLD


#3

Michael D. wrote:

Johnathan - I was away on travel while this was released, but now
that I’m back I checked this 3.0.3 release out on both Intel and PPC
OSX, and make, make check, make distcheck, etc… all work great.

Thanks for testing.

I’m -quite- stumped by the lack of functionality on PPC-OSX by the
trunk. The primary significant change that I can think of between
3.0.3 and trunk is the movement of omnithread from gnuradio-core to
its own library space (gromnithread) … correct me if I’m wrong in
this belief. Now that I’m back, I’m back to investigating this issue
… truly strange. - MLD

Can you capture all the details of the failure in a ticket in Trac? (Or
maybe it’s there and I missed it.)

You’re right, the chief difference in the build system between the
stable release and the development trunk is that the trunk has several
more top-level components–omnithreads was pulled out of the core to
become it’s own library, and there are the pmt and mblock components
which do don’t directly depend on gnuradio-core.

Of course there are major changes in many areas of functionality, and as
we approach completion of these we’ll be looking more and more towards
stabilizing things to eventually cut a new 3.1 stable branch.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com


#4

I just posted this on the Ticket:
< http://gnuradio.org/trac/ticket/141 >
The error was introduced in [4255]. I can verify this because [4254]
compiles and does “make check” while [4255] does not (the “make
check” part). I truly have no idea why the changes work on an Intel-
Mac, but not on a PPC-Mac. - MLD


#5

On Mar 2, 2007, at 12:59 PM, Johnathan C. wrote:

Can you capture all the details of the failure in a ticket in Trac?
(Or
maybe it’s there and I missed it.)

http://www.gnuradio.org/trac/ticket/141


#6

Got it! It’s the line:

swig_CXXFLAGS="-g1 -O1"

in “gnuradio/configure.ac”. Changing this to “-O2” does the trick.
I’ve created a branch at < http://gnuradio.org/svn/gnuradio/branches/
developers/michaelld/t141 > with the change. I don’t think it will
affect any other os except Darwin … hope I got the syntax correct.
It works for me. Here’s the svn diff:

Index: configure.ac

— configure.ac (revision 4720)
+++ configure.ac (working copy)
@@ -49,7 +49,15 @@
autoconf_default_CXXFLAGS="$CXXFLAGS"
CXXFLAGS=""
if test “$GXX” = yes; then

  • swig_CXXFLAGS="-g1 -O1"
  • case “$host_os” in
  •   darwin*)
    
  •   # "-O1" breaks PPC-OSX for some reason
    
  •   swig_CXXFLAGS="-g -O2"
    
  •   ;;
    
  •   *)
    
  •   swig_CXXFLAGS="-g1 -O1"
    
  •   ;;
    
  • esac
    fi
    fi
    AC_SUBST(autoconf_default_CXXFLAGS)

#7

On Mar 5, 2007, at 11:21 PM, Eric B. wrote:

you made two changes:

-g1 -> -g
-O1 -> -O2

Does -g -O1 work on PPC-OSX?

We really want to “turn down” the level of optimization used while
compiling the SWIG stuff. The SWIG stuff is not performance critical,
and using a lower level of optimization speeds up the compilation.

Here are the results of “time make -j3” from compiling with different
options (as listed; run only once, so not statistically significant
but still useful). After compiling, I run “make check” and it either
works ("+") or doesn’t ("-") in the sense of ticket:141.

  1. “-g -O2”
    Intel +: 514.437u 225.594s 7:28.93 164.8% 0+0k 159+2045io 0pf+0w
    PPC +: 790.567u 437.716s 11:45.85 174.0% 0+0k 12+2514io 0pf+0w

  2. “-g1 -O2”
    Intel +: 511.048u 227.164s 7:23.83 166.3% 0+0k 115+2063io 0pf+0w
    PPC +: 779.509u 435.124s 11:35.84 174.5% 0+0k 1+2317io 0pf+0w

  3. “-g -O1”
    Intel +: 485.501u 229.842s 7:20.63 162.3% 0+0k 0+2061io 0pf+0w
    PPC -: 729.166u 436.894s 11:10.46 173.9% 0+0k 0+2395io 0pf+0w

  4. “-g1 -O1”
    Intel +: 481.946u 229.679s 7:11.07 165.0% 0+0k 0+1975io 0pf+0w
    PPC -: 724.620u 443.608s 11:10.59 174.2% 0+0k 0+2394io 0pf+0w

Thus for PPC-OSX, (2) is the best choice while for Intel-OSX (4) is
the best. I’ve modified configure.ac to handle those cases, and it
works fine on both PPC- and Intel-OSX for me. Again, it won’t affect
any OS except Darwin.

NOTE: On PPC-OSX, those that work ("+") always get the following
failure:
+++++++++++++++++++++++++
FAIL: test_pll_refout (main.test_sig_source)

Traceback (most recent call last):
File “./qa_pll_freqdet.py”, line 158, in test_pll_refout
self.assertFloatTuplesAlmostEqual (expected_result, dst_data, 4)
File “/GNURadio/t141/gnuradio-core/src/python/gnuradio/
gr_unittest.py”, line 86, in assertFloatTuplesAlmostEqual
self.assertAlmostEqual (a[i], b[i], places, msg)
AssertionError: 98.939748723299999 != 98.939695362490014 within 4 places
+++++++++++++++++++++++++


#8

On Mon, Mar 05, 2007 at 10:26:20PM -0500, Michael D. wrote:

Index: configure.ac

  •   # "-O1" breaks PPC-OSX for some reason
    
  •   swig_CXXFLAGS="-g -O2"
    
  •   ;;
    
  •   *)
    
  •   swig_CXXFLAGS="-g1 -O1"
    
  •   ;;
    
  • esac
    fi
    fi
    AC_SUBST(autoconf_default_CXXFLAGS)

Michael, this is great info.

you made two changes:

-g1 -> -g
-O1 -> -O2

Does -g -O1 work on PPC-OSX?

We really want to “turn down” the level of optimization used while
compiling the SWIG stuff. The SWIG stuff is not performance critical,
and using a lower level of optimization speeds up the compilation.

Eric


#9

On Tue, Mar 06, 2007 at 11:04:43AM -0500, Michael D. wrote:

and using a lower level of optimization speeds up the compilation.

  1. “-g1 -O2”

Traceback (most recent call last):
File “./qa_pll_freqdet.py”, line 158, in test_pll_refout
self.assertFloatTuplesAlmostEqual (expected_result, dst_data, 4)
File “/GNURadio/t141/gnuradio-core/src/python/gnuradio/
gr_unittest.py”, line 86, in assertFloatTuplesAlmostEqual
self.assertAlmostEqual (a[i], b[i], places, msg)
AssertionError: 98.939748723299999 != 98.939695362490014 within 4 places
+++++++++++++++++++++++++

Thanks for running all the experiments.

Regarding the failure in test_pll_refout, I suspect that this depends
on minor differences in floating point implementations. E.g.,
x87 FPU, scalar SSE, or Altivec. I think we should just ease the
criterion on the test. Will you please change the “4” to a “3”?

With regard to the real failures in the two -O1 cases, that looks like
a genuine compiler bug.

Eric