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.
Johnathan C. (Guest)
on 2007-02-27 01: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 C.
Corgan Enterprises LLC
http://corganenterprises.com
Eric B. (Guest)
on 2007-02-27 02:10
(Received via mailing list)
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
Berndt Josef W. (Guest)
on 2007-02-27 02: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
Greg T. (Guest)
on 2007-02-27 02: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 T. <removed_email_address@domain.invalid>
Berndt Josef W. (Guest)
on 2007-02-27 03: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
Eric B. (Guest)
on 2007-02-27 03:57
(Received via mailing list)
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
Greg T. (Guest)
on 2007-02-27 04:14
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
removed_email_address@domain.invalid
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Eric B. (Guest)
on 2007-02-27 04:31
(Received via mailing list)
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 :-)

Wow, that sounds like a great idea!  ;)

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

Eric
Greg T. (Guest)
on 2007-02-27 05:02
(Received via mailing list)
Eric B. <removed_email_address@domain.invalid> 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.
Berndt Josef W. (Guest)
on 2007-02-27 05: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
Eric B. (Guest)
on 2007-02-27 06:27
(Received via mailing list)
On Mon, Feb 26, 2007 at 10:02:02PM -0500, Greg T. wrote:
> >>
> >
> packages consistently built from the same release tarball.
I concur.
Johnathan C. (Guest)
on 2007-02-28 04:50
(Received via mailing list)
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
Berndt Josef W. (Guest)
on 2007-02-28 05:11
(Received via mailing list)
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
This topic is locked and can not be replied to.