Forum: GNU Radio GNU Radio Release 3.0.3 Available

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Johnathan C. (Guest)
on 2007-02-28 22:35
(Received via mailing list)
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-wri...

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
Michael D. (Guest)
on 2007-03-02 19:11
(Received via mailing list)
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 C. (Guest)
on 2007-03-02 20:00
(Received via mailing list)
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
Michael D. (Guest)
on 2007-03-02 20:44
(Received via mailing list)
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
Michael D. (Guest)
on 2007-03-06 04:35
(Received via mailing list)
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
Michael D. (Guest)
on 2007-03-06 05:27
(Received via mailing list)
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)
Eric B. (Guest)
on 2007-03-06 06:17
(Received via mailing list)
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
Michael D. (Guest)
on 2007-03-06 18:06
(Received via mailing list)
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
+++++++++++++++++++++++++
Eric B. (Guest)
on 2007-03-06 22:46
(Received via mailing list)
On Tue, Mar 06, 2007 at 11:04:43AM -0500, Michael D. wrote:
> >and using a lower level of optimization speeds up the compilation.
> 2) "-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 topic is locked and can not be replied to.