Release candidate 3.0.3rc2 available for testing

All,

GNU Radio release candidate 3.0.3rc2 is available for testing:

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

This is a bug fix and very minor enhancement release to the existing 3.0
stable branch. All relevant issues that have been corrected on the main
development trunk have been back-ported.

Details on the changes since release 3.0.3rc1 are listed here:

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

As usual, please report any problems via the Trac ticket system, using
the ‘guest’ account with password ‘gnuradio’:

http://gnuradio.org/trac/


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

On Mon, Feb 26, 2007 at 03:01:04PM -0800, Johnathan C. wrote:

Johnathan C.
Thanks Johnathan, for working through the linking stuff, and getting
this release candidate out!

Eric

G’day,

latest release candidate breaks when compiling individual packages. This
is
due to intree dependencies that are nolonger satisfied under the
following
condition, e.g.:

./configure --prefix=/usr/pkg --disable-all-components
–enable-gr-audio-oss

resulting in:

gmake[4]: Entering directory
/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/src' gmake[4]: *** No rule to make target…/…/gnuradio-core/src/lib/libgnuradio-core.la’, needed by
_audio_oss.la'. Stop. gmake[4]: Leaving directory/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/src’
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss’
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2’
gmake: *** [all] Error 2
*** Error code 2

With this in place, pkgsrc will nolonger be able to build individual
packages
for each module as in the past.

cheerio Berndt

Do the packages install the .la file? Perhaps some sort of
conditional that uses in-tree for configured component and in-$libdir
for unconfigured components would be the right thing.


Greg T. [email protected]

My guess is that one could make it a special case
of “disable-all-components --enable-XXXX” when building a specific
component.

pkgsrc builds packages in a sandbox filesystem containing all package
dependencies hence it was never an issue.

cheerio Berndt


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On Mon, Feb 26, 2007 at 09:13:15PM -0500, Greg T. wrote:

or

$(libdir)/libgnuradio-foo.la

depending on whether the component is enabled or not.
This would, I think, safely link against the intended library.

(I can hear you saying to create a trial fix branch with this :slight_smile:

Wow, that sounds like a great idea! :wink:

Is it your assumption that we’d always build using the build-tree
includes?

Eric

Eric B. [email protected] writes:

Is it your assumption that we’d always build using the build-tree
includes?

I didn’t think about that much, but the above suggestion results in
using the build-tree includes. Arguably the installed includes for
just those components should be used, but CPPFLAGS isn’t powerful
enough to do that. In practice it doesn’t matter, since pkgsrc and
hopefully other packaging system using this technique would have all
packages consistently built from the same release tarball.

On Tue, Feb 27, 2007 at 11:39:36AM +1030, Berndt Josef W. wrote:

gmake[4]: Entering directory
/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/src' gmake[4]: *** No rule to make target…/…/gnuradio-core/src/lib/libgnuradio-core.la’, needed by `_audio_oss.la’.
Stop.

FYI, this isn’t new behavior. It’s been like this (or should have
been like this) since the build system overhaul.

I understand your desire to build individual pieces, but that hasn’t
been coded up yet.

Eric

On Tuesday 27 February 2007 12:31:13 you wrote:

resulting in:
I understand your desire to build individual pieces, but that hasn’t
been coded up yet.

Eric

I beg to differ. It worked within the pkgsrc environment and only broke
in
recent RC2.

cheerio Berndt

Berndt Josef W. wrote:

I beg to differ. It worked within the pkgsrc environment and only broke in
recent RC2.

Yes, it appears this was “accidentally” working before, as we were
allowing the system library paths to be included when building inside
the tree. Now that we’ve cleaned things up, we’ll need to come up with
a different way for this to succeed.

Greg T. has an idea (posted earlier) to address this; unfortunately,
it’s too large of a change to make it into the stable branch until we
get thorough testing on the trunk. So release 3.03 will work as-is.


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

On Wednesday 28 February 2007 13:19:12 you wrote:

Berndt Josef W. wrote:

I beg to differ. It worked within the pkgsrc environment and only broke
in recent RC2.

Yes, it appears this was “accidentally” working before, as we were
allowing the system library paths to be included when building inside
the tree. Now that we’ve cleaned things up, we’ll need to come up with
a different way for this to succeed.

By my recollection it was the intent of having these switches to enable
developers to select and build individual modules.

Greg T. has an idea (posted earlier) to address this; unfortunately,
it’s too large of a change to make it into the stable branch until we
get thorough testing on the trunk. So release 3.03 will work as-is.

In this case I will base the pkgsrc collection on RC1 for now, which I
have
ready for commit.

It would be nice to see a solution for future releases.

cheerio Berndt

On Mon, Feb 26, 2007 at 10:02:02PM -0500, Greg T. wrote:

packages consistently built from the same release tarball.
I concur.