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:
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:
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.
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
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.
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
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
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.
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
+++++++++++++++++++++++++
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.
On Tue, Mar 06, 2007 at 11:04:43AM -0500, Michael D. wrote:
and using a lower level of optimization speeds up the compilation.
“-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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.