GNU Radio 3.1.2rc0 tarballs available for testing

GNU Radio release 3.1.2rc0 tarballs are now available for testing:

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

Release 3.1.2rc0 is a pre-release for testing purposes, and
incorporates all known bug fixes from the development trunk. In
addition, new features and functions that don’t (or shouldn’t) impact
existing user code have been included:

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

Instructions for installation may be found at:

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

Source code-based installation of GNU Radio requires ensuring the
build prerequisites are installed on your system, followed by the
traditional ‘configure’ and ‘make’ process. See the OS specific
instructions at the above wiki page to accomplish this.


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

The installation instructions for MinGW are still geared toward 3.0. I
believe 3.1 requires Python 2.5/NumPy rather than Python 2.4/Numeric.
Is that correct? Also, have any other dependencies changed?

Instructions for installation may be found at:

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

Source code-based installation of GNU Radio requires ensuring the
build prerequisites are installed on your system, followed by the
traditional ‘configure’ and ‘make’ process. See the OS specific
instructions at the above wiki page to accomplish this.

Thanks,

Rob

Robert W. wrote:

The installation instructions for MinGW are still geared toward 3.0. I
believe 3.1 requires Python 2.5/NumPy rather than Python 2.4/Numeric.
Is that correct? Also, have any other dependencies changed?

It has been a while since I have reviewed these instructions. GNU Radio
3.1
needs NumPy but still works fine with Python 2.4. I am not aware of
other
dependencies that have changed. I will check and update the wiki for
3.1.2
when that release is finalized.

– Don W.

On 3/15/08, Berndt Josef W. [email protected] wrote:

Needless to say, svn is installed and accessable. No idea about
omnithread. Any suggestions appreciated.

The svn comment is harmless; it’s a side effect of using a tarball
instead of an svn checked out source tree.

It looks like your ./configure line in pkgsrc doesn’t have the
omnithread module specified. That would be done with
‘–enable-omnithread’ if you are including it in the build, or using
the new ‘–with-omnithread’ syntax if you are referring an already
installed instance of libgromnithread.


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

On Thursday 13 March 2008 05:27:30 Johnathan C. wrote:

impact existing user code have been included:
instructions at the above wiki page to accomplish this.
Doesn’t build using the pkgsrc framework failing as shown below:

checking boost/shared_ptr.hpp presence… yes
checking for boost/shared_ptr.hpp… yes
checking for svn… /usr/pkg/bin/svn
svn: ‘.’ is not a working copy
svn: ‘.’ is not a working copy
Not building component omnithread.
Component gnuradio-core requires omnithread, which is not being
built or specified via pre-installed files.

Needless to say, svn is installed and accessable. No idea about
omnithread. Any suggestions appreciated.

Systeminfo: NetBSD 4.99.51 (GENERIC)

73, Berndt
VK5ABN

On Saturday 15 March 2008 23:44:43 Berndt Josef W. wrote:

Not building component omnithread.
omnithread module specified. That would be done with
‘–enable-omnithread’ if you are including it in the build, or
using the new ‘–with-omnithread’ syntax if you are referring
an already installed instance of libgromnithread.

hmm, I’ve used the --enable-omnithread option. I don’t know of
any package that would provide me with the libgromnithread
library.

BTW: Which package does provide libgromnithread?

cheerio Berndt

On Saturday 15 March 2008 23:16:21 Johnathan C. wrote:

Component gnuradio-core requires omnithread, which is not
‘–enable-omnithread’ if you are including it in the build, or
using the new ‘–with-omnithread’ syntax if you are referring an
already installed instance of libgromnithread.

hmm, I’ve used the --enable-omnithread option. I don’t know of any
package that would provide me with the libgromnithread library.

Will investigate this further,

cheerio Berndt

The svn comment is harmless; it’s a side effect of using a tarball
instead of an svn checked out source tree.

Why does configure look for svn at all?

BTW: Which package does provide libgromnithread?

See README.components for how to deal with this. This splits all of the
pieces of GNU Radio into independent builds. It probably does not make
sense to have one pkgsrc package per component, and probably
“gnuradio-core” should have a bunch of components in it. Basically, I
see no reason for someone to want to install pmt but not gnuradio-core -
the real reason to split is to avoid depdendencies or huge things.

On 3/15/08, Greg T. [email protected] wrote:

Why does configure look for svn at all?

If configure runs from an svn checked out repository, the makefiles
end up with some variables set to the repository version and last
changed date.


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

On 3/15/08, Greg T. [email protected] wrote:

See README.components for how to deal with this. This splits all of the
pieces of GNU Radio into independent builds. It probably does not make
sense to have one pkgsrc package per component, and probably
“gnuradio-core” should have a bunch of components in it. Basically, I
see no reason for someone to want to install pmt but not gnuradio-core -
the real reason to split is to avoid depdendencies or huge things.

BTW, the README.components script is in the trunk only, not part of
the regular release. The build dependencies of the trunk are
substantially different and the script would not work for the 3.1.2
release. In case anyone is wondering, this script is an example of
an alternative way to build GNU Radio, primarily of interest to *BSD
users.


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

“Johnathan C.” [email protected] writes:

the regular release. The build dependencies of the trunk are
substantially different and the script would not work for the 3.1.2

Sorry, I was confused about what was in the release candidate and
Berndt’s build troubles caused me to jump to the wrong conclusion.

release. In case anyone is wondering, this script is an example of
an alternative way to build GNU Radio, primarily of interest to *BSD
users.

Just to clarify a bit:

The alternative fine-grained build (besides being useful for ensuring
the build procedure is squeaky-clean) is aimed at packaging systems that
want to make a number of packages from one source tarball and do so with
multiple separate builds, rather than one build and then having N
separate lists of files. For build GNU Radio from svn as a regular user
rather than package maintainer on *BSD, the existing build system works
fine.

On Sat, Mar 15, 2008 at 06:37:42AM -0700, Johnathan C. wrote:

On 3/15/08, Greg T. [email protected] wrote:

Why does configure look for svn at all?

If configure runs from an svn checked out repository, the makefiles
end up with some variables set to the repository version and last
changed date.

Maybe you ought to first test for the presence of the .svn directory.
If it’s not there, there’s no reason to look for or run the svn command.

Eric

Eric B. wrote:

Maybe you ought to first test for the presence of the .svn directory.
If it’s not there, there’s no reason to look for or run the svn command.

Greg just did this and checked it in.

-Johnathan

I was attempting to use Chuck Swiger’s utility at
http://www.swigerco.com/gnuradio/raw2num_f.c to read a gnuradio file
created by audio_to_file.py but kept getting “Input reached EOF” well
before the entire file had been read. I am not a C programmer, but
while debugging I noticed that he had used “r” in his fopen command
rather than the “rb” used by gr_file_source.cc so I made that change and
now the utility works fine. I also noticed an old post from ematlis
(http://lists.gnu.org/archive/html/discuss-gnuradio/2007-05/msg00341.htm
l) mentioning a similar utility he’d developed and noticed it uses “r”
rather than “rb” also. Shouldn’t “rb” be used rather than “r” to open
gnuradio data files?

By the way, I am using MinGW/MSYS with GCC 3.4.5 if that matters.

Thanks,

Rob

Rob Walker wrote:

gnuradio data files?

By the way, I am using MinGW/MSYS with GCC 3.4.5 if that matters.

Windows (MinGW/MSYS and Cygwin) needs to know when to convert the CR-LF
line
separators stored in a text file to LF on reading (text files) and when
to
leave them alone (binary data). For portability, I think that all files
that are not text files should be opened with “rb”.

– Don W.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs