Forum: GNU Radio Release candidate 3.0.3rc2 available for testing

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.
Cec0a4bf0e0575f3a3171892e6097e59?d=identicon&s=25 Johnathan Corgan (Guest)
on 2007-02-27 00:03
(Received via mailing list)
All,

GNU Radio release candidate 3.0.3rc2 is available for testing:

http://gnuradio.org/releases/gnuradio/gnuradio-3.0...
http://gnuradio.org/releases/gnuradio/gr-howto-wri...

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 Corgan
Corgan Enterprises LLC
http://corganenterprises.com
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-02-27 01:10
(Received via mailing list)
On Mon, Feb 26, 2007 at 03:01:04PM -0800, Johnathan Corgan wrote:
>
> Johnathan Corgan
Thanks Johnathan, for working through the linking stuff, and getting
this release candidate out!

Eric
Dbdc5157899fcad4f0afbd8fd5875688?d=identicon&s=25 Berndt Josef Wulf (Guest)
on 2007-02-27 01:11
(Received via mailing list)
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
5e81c66258333eb8e665cc4814d0a6d5?d=identicon&s=25 Greg Troxel (Guest)
on 2007-02-27 01:28
(Received via mailing list)
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 Troxel <gdt@ir.bbn.com>
Dbdc5157899fcad4f0afbd8fd5875688?d=identicon&s=25 Berndt Josef Wulf (Guest)
on 2007-02-27 02:40
(Received via mailing list)
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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-02-27 02:57
(Received via mailing list)
On Tue, Feb 27, 2007 at 11:39:36AM +1030, Berndt Josef Wulf 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
5e81c66258333eb8e665cc4814d0a6d5?d=identicon&s=25 Greg Troxel (Guest)
on 2007-02-27 03:14
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-02-27 03:31
(Received via mailing list)
On Mon, Feb 26, 2007 at 09:13:15PM -0500, Greg Troxel 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 :-)

Wow, that sounds like a great idea!  ;)

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

Eric
5e81c66258333eb8e665cc4814d0a6d5?d=identicon&s=25 Greg Troxel (Guest)
on 2007-02-27 04:02
(Received via mailing list)
Eric Blossom <eb@comsec.com> 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.
Dbdc5157899fcad4f0afbd8fd5875688?d=identicon&s=25 Berndt Josef Wulf (Guest)
on 2007-02-27 04:58
(Received via mailing list)
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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-02-27 05:27
(Received via mailing list)
On Mon, Feb 26, 2007 at 10:02:02PM -0500, Greg Troxel wrote:
> >>
> >
> packages consistently built from the same release tarball.
I concur.
Cec0a4bf0e0575f3a3171892e6097e59?d=identicon&s=25 Johnathan Corgan (Guest)
on 2007-02-28 03:50
(Received via mailing list)
Berndt Josef Wulf 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 Troxel 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 Corgan
Corgan Enterprises LLC
http://corganenterprises.com
Dbdc5157899fcad4f0afbd8fd5875688?d=identicon&s=25 Berndt Josef Wulf (Guest)
on 2007-02-28 04:11
(Received via mailing list)
On Wednesday 28 February 2007 13:19:12 you wrote:
> Berndt Josef Wulf 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 Troxel 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
This topic is locked and can not be replied to.