Test tarballs for 3.3git

GNU Radio
1

Test tarball distribution files have been created for the current
3.3git release under development:

http://gnuradio.org/releases/gnuradio/gnuradio-3.3git-594-g02616cf8.tar.gz
http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3git-594-g02616cf8.tar.gz

These distribution files should compile and install using the same
configure, make, make install process as the current 3.2.2 release
files do. The purpose of providing these is to test the distribution
tarball creation process, which can fail in ways that wouldn’t affect
building from a repository checkout. The full set of features for 3.3
release is not in them, nor are there release notes. However, the
resulting build should be identical to what you would get if you were
to build from our current git master.

A word on naming–pre-release tarballs will have 3.3git, followed by
the number of revisions since the last tag in the repository, followed
by the shortened git commit id they are based on. In this case, we
put in a 3.3git tag in the repo when we did the conversion from
Subversion, so there have been 594 commits along the master branch
since then. (This naming is derived from the output of ‘git
describe’).

For USRP2 users, the associated image files for the firmware and FPGA,
respectively, are:

http://gnuradio.org/releases/usrp2-bin/trunk/txrx_edk10.1_3.3git-594-g02616cf8.bin
http://gnuradio.org/releases/usrp2-bin/trunk/u2_rev3_ise10.1sp3_3.3git-594-g02616cf8.bin

Remember, this is not a stable release, but a snapshot of our current
development for 3.3. If this turns out to be useful (as measured by
feedback on the list or the wiki), we may automate this.

Finally, pending further testing, binary packages for Ubuntu 9.10 for
this version will be created; those tracking ‘unstable’ in their
package manager will get these automatically when they are ready.

Thank you,

Johnathan C.
Corgan Enterprises LLC

2

Il 17/01/2010 19:32, Johnathan C. ha scritto:

building from a repository checkout. The full set of features for 3.3
describe’).

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

will these new *.deb binaries be good for updating on ubuntu 9.04 too ?
or are they for ubuntu 9.10 specific only?

thx in advance for the answer

Bye

3

On Tue, Jan 19, 2010 at 05:57, Arturo R. [email protected]
wrote:

will these new *.deb binaries be good for updating on ubuntu 9.04 too ? or
are they for ubuntu 9.10 specific only?

Right now they will be for Ubuntu 9.10. Unfortunately, 9.04 and 9.10
do not ship with a common version of Boost, so I would have to build a
separate set of .debs for 9.04. I may do that if I get the time.

Johnathan

4

Il 19/01/2010 19:10, Johnathan C. ha scritto:

Johnathan

thank you very much. it would be appreciated (i think) not only by
myself :wink:

Bye, Arturo :wink:

5

Johnathan C. wrote:

Test tarball distribution files have been created for the current
3.3git release under development:

http://gnuradio.org/releases/gnuradio/gnuradio-3.3git-594-g02616cf8.tar.gz

Apart from one or two minor issues, this tarball works fine under Cygwin
1.7.1 with gcc 3.4.4, but with gcc 4.3.4 make check fails with

~/gnuradio-3.3git-594-g02616cf8/gnuradio-core/src/tests> ./test_all.exe
Testing gr_vmcircbuf_createfilemapping_factory…
… gr_vmcircbuf_createfilemapping_factory: OK
Testing gr_vmcircbuf_sysv_shm_factory…
terminate called after throwing an instance of ‘gr_signal’
Aborted (core dumped)

It appears that a signal is being caught and a gr_signal is being thrown
but
not caught.

This is probably a Cygwin-specific problem with exception handling in
gcc
4.3.4, but if anyone else has seen problems like this and has any
insight as
to the cause, I would like to hear about it.

Thanks,

– Don W.

6

On Fri, Jan 22, 2010 at 13:52, Don W. [email protected] wrote:

Apart from one or two minor issues, this tarball works fine under Cygwin
1.7.1 with gcc 3.4.4

Thanks for testing.

not caught.

This is probably a Cygwin-specific problem with exception handling in gcc
4.3.4, but if anyone else has seen problems like this and has any insight as
to the cause, I would like to hear about it.

The code itself has a try/catch block wrapped around the QA tests,
with handlers for anticipated exceptions and a default uncaught
exception handler. The fact that exception gr_signal is being thrown
is probably correct, but that fact that execution blows out the top of
the try/catch block instead of being caught is definitely not correct.

Johnathan