On Thu, Aug 10, 2006 at 08:16:57PM -0700, Johnathan Corgan wrote:
> Greg Troxel wrote:
> >It seems that GNU make is required; compiling with BSD make gives "no
> >input files", a classic sign of a GNU make extension being used to set
> >a list of files.
> >
> >This is not noted in README. It could
Thomas Schmid wrote:
I think someone should update the gnuradio website
http://www.gnu.org/software/gnuradio/ and point to the directions for
trac. It still shows how to get the CVS code, especially since that
code will soon be unavailable.
This is logged already as ticket #20. We're working on
Greg Troxel wrote:
It seems that GNU make is required; compiling with BSD make gives "no
input files", a classic sign of a GNU make extension being used to set
a list of files.
This is not noted in README. It could be in step 2 of how to build,
or probably in the list of prerequisites in step 1
The USRP has a 64 MHz clock onboard which gives a 64 MS/s ADC and 128
MS/s DAC. To change that, you can use the external clock mode, or you
can replace the clock with another one. The pin-compatible family is
from CTS and contains many different frequencies. The 64 MHz clock is
part numbe
On Thu, 2006-08-10 at 11:56 -0700, Johnathan Corgan wrote:
> Ticket #13 was reporting failure with parallel makes.
>
> This was failing in gnuradio-core, but was fixed back in r3222.
>
> Those of you tracking the new svn trunk--could you test this and confirm?
>
I tried the svn source with "mak
On Thu, Aug 10, 2006 at 04:22:30PM -0400, Michael Dickens wrote:
> On a Dual G5 OSX 10.4.7, "make -j" results in lots of:
>
> /opt/local/bin/glibtool: fork: Resource temporarily unavailable
>
> and
>
> powerpc-apple-darwin8-g++-4.0.1: : No such file or directory
>
> and
>
> /bin/sh: fork: Reso
I think someone should update the gnuradio website
http://www.gnu.org/software/gnuradio/ and point to the directions for
trac. It still shows how to get the CVS code, especially since that
code will soon be unavailable.
Cheers,
Thomas
___
Discuss-gnu
On a Dual G5 OSX 10.4.7, "make -j" results in lots of:
/opt/local/bin/glibtool: fork: Resource temporarily unavailable
and
powerpc-apple-darwin8-g++-4.0.1: : No such file or directory
and
/bin/sh: fork: Resource temporarily unavailable
Running it time after time slowly gets everything made.
On Thu, August 10, 2006 12:43, Michael Dickens wrote:
> 1) From usrp/host/apps/test_usrp_standard_rx.cc
> and
> ._tx.cc:
>
> HAVE_SCHED_SETSCHEDULER is used to try to set a real-time scheduler.
> W/o it, "real time" ("-R") has no effect. THis is the only reference
> in the USRP's code to this
It seems that GNU make is required; compiling with BSD make gives "no
input files", a classic sign of a GNU make extension being used to set
a list of files.
This is not noted in README. It could be in step 2 of how to build,
or probably in the list of prerequisites in step 1 that lists
autoconf
On Thu, August 10, 2006 12:23, Greg Troxel wrote:
> And really, the Makefile.common for the gnuradio family will set the
> distfile and
You're of course referring to the pkgsrc makefile here.
> Indeed. Thanks for accomodating this in the gnuradio repo; it's far
> easier to spiff things up there
On Aug 10, 2006, at 3:31 PM, Johnathan Corgan wrote:
On Thu, August 10, 2006 12:20, Michael Dickens wrote:
... so both the "byteswap" and "sched_setscheduler" are killing my
configure for the USRP. When I change these to:
AC_CHECK_FUNCS([getrusage],[],[succeeded=no])
AC_CHECK
On Thu, August 10, 2006 12:20, Michael Dickens wrote:
> ... so both the "byteswap" and "sched_setscheduler" are killing my
> configure for the USRP. When I change these to:
>
> AC_CHECK_FUNCS([getrusage],[],[succeeded=no])
> AC_CHECK_HEADERS([byteswap.h])
>
> then everything works as
"Johnathan Corgan" <[EMAIL PROTECTED]> writes:
> On Thu, August 10, 2006 11:52, Greg Troxel wrote:
>
>> What I really want is an easy way to build each component by
>> downloading some tarball (can be same for all) and doing some sort of
>> ./configure argument and ending up with only each logica
The new m4 script says
AC_CHECK_FUNCS([getrusage sched_setscheduler],[],[succeeded=no])
AC_CHECK_HEADERS([byteswap.h],[],[succeeeded=no])
while the old one says
AC_CHECK_FUNCS([getrusage])
AC_CHECK_HEADERS([byteswap.h])
... so both the "byteswap" and "sched_sets
On Thu, August 10, 2006 11:52, Greg Troxel wrote:
> What I really want is an easy way to build each component by
> downloading some tarball (can be same for all) and doing some sort of
> ./configure argument and ending up with only each logical component
> installed. Your detailed suggestion sou
Ticket #13 was reporting failure with parallel makes.
Invoking (after bootstrap & configure) make with the -j option causes it
to run as many instances in parallel as possible, dependencies allowing,
in order to take advantage of multiple processors or cores, or to have a
second instance run while
"Johnathan Corgan" <[EMAIL PROTECTED]> writes:
> Eric and I discussed doing something like this but deferred it until we
> got the new build stabilized. We're pretty close to that point, modulo
> some nits that keep showing up on certain platforms that I can't directly
> test on.
>
> To confirm:
On Thu, August 10, 2006 11:36, Tom Rondeau wrote:
> (I'm going to switch the other machine back to gcc 3.4.6 to keep everyone
> consistent, but if this is in fact a problem with the gcc version, I
> thought
> it should be known.)
>
> By the way, to all those involved (Johnathan especially), great
So after a few weeks of working on my cognitive radio code, I've finally
gotten back to some GNU Radio work (just got a few new RF boards in and I'm
itching to do some networking). I've just today moved to the SVN code base,
and two out of three machines successfully installed everything on the fir
On Thu, August 10, 2006 11:22, Michael Dickens wrote:
> Hmm ... I don't see anything obviously "wrong" or out of place w/
> configure or the m4 script. Here's the output of configure:
These lines are causing usrp to fail:
checking byteswap.h usability... no
checking byteswap.h presence... no
ch
Hmm ... I don't see anything obviously "wrong" or out of place w/
configure or the m4 script. Here's the output of configure:
rm: conf8028: Directory not empty
checking build system type... powerpc-apple-darwin8.7.0
checking host system type... powerpc-apple-darwin8.7.0
checking target system
On Thu, August 10, 2006 09:55, Michael Dickens wrote:
> I haven't changed my DarwinPorts stuff since moving from the "old"
> GNU Radio model to the new one. The "old" style worked just fine for
> compiling each module independently, so I don't know why the "new"
> one wouldn't work too. Do I hav
On Thu, August 10, 2006 10:13, Greg Troxel wrote:
> How will the new structure affect upcoming releases? NetBSD pkgsrc
> currently builds separate packages for each GNU Radio component, which
> lets one install them separately and also avoid dependencies for
> things you don't need. Will this ju
How will the new structure affect upcoming releases? NetBSD pkgsrc
currently builds separate packages for each GNU Radio component, which
lets one install them separately and also avoid dependencies for
things you don't need. Will this just be 'make dist' and a single
tarball?
pkgsrc, unlike so
I haven't changed my DarwinPorts stuff since moving from the "old"
GNU Radio model to the new one. The "old" style worked just fine for
compiling each module independently, so I don't know why the "new"
one wouldn't work too. Do I have to have USRP hardware connected at
the time of config
On Thu, August 10, 2006 09:33, Michael Dickens wrote:
> OK. I did the "new style" compile on an anonymous check-out this
> morning. All the bootstrap and configure went OK, except that it
> doesn't want to install the USRP and GR-USRP. Whatever. "make" went
> fine. "make check" also passed ev
OK. I did the "new style" compile on an anonymous check-out this
morning. All the bootstrap and configure went OK, except that it
doesn't want to install the USRP and GR-USRP. Whatever. "make" went
fine. "make check" also passed everything. So, at least for my
trial today, everything
On Thu, August 10, 2006 06:48, Michael Dickens wrote:
> OSX libraries are created with a specific directory location as an
> attribute. So not only does the library have to be in the correct
> place (the attribute location), but if it's a non-standard location
> then the environment variable "DYL
Nope, no news. My sollution was to install Ubuntu on my macbook. That
works just fine.
I will try XCode 2.4. Didn't know that it is released.
Thomas
On 8/10/06, Michael Dickens <[EMAIL PROTECTED]> wrote:
Thomas - Did you make progress on this? I'm wondering if it's an
Intel-MacBook issue, sin
OK. So .dat files don't play audio on OSX under portaudio or audio-
osx. Can anyone confirm that these same .dat files do play audio on
any other OS, and thus it's an OSX-specific issue? Or is it possibly
a more general GNU Radio issue? I have only PPC Macs to work with,
so I can't test
Thomas - Did you make progress on this? I'm wondering if it's an
Intel-MacBook issue, since it doesn't seem to pop up for the MacBook
Pro, nor Intel-mini, nor Intel-iMac (or, at least I haven't heard of
such a thing).
I doubt it will help, but you can try XCode 2.4 now that it's
released
I'm still compiling the new SNV stuff, for the purposes of debugging
the install procedure & updating my install guide ... I don't have
commit access yet as far as I know, so I can't change anything if I
do find issues.
OSX libraries are created with a specific directory location as an
at
I am wondering: in 'make check', given that the libraries haven't
actually been installed, which piece of magic allows python to resolve
its imports?
I am trying to get the new SVN build working on OSX, but I get stranded
in the "make check" for gr-audio-osx. If somebody could tell me how the
34 matches
Mail list logo
