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
imports are supposed to work, I can probably figure it out.
This was filed as defect #26.
I am really surprised that I got this far. Great work, guys!
Cheers,
Jan
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
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 "DYLD_LIBRARY_PATH
" must be set with that path in mind (as well as other paths,
potentially, to get the load path correct). Setting this variable
will -really- screw things up, so don’t do it on a global basis.
OTOH, for a local check, it is possible to create libraries with a
local (tmp) path in mind, set the DYLD_LIBRARY_PATH to point to that
location, then do the “check” part of “make check”.
I don’t know if GNU Radio does all this stuff or not. Last time I
remember, “make check” failed under OSX for just this reason … the
dyld’s couldn’t be found.
If nobody else has a fix for this issue, then I’ll add it to my
queue … at a low priority for now since it’s simple enough to “make
install” then “make check” instead of the reverse. - MLD
On Thu, August 10, 2006 06:48, Michael D. 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 "DYLD_LIBRARY_PATH
" must be set with that path in mind (as well as other paths,
potentially, to get the load path correct).
I’m traveling at the moment and can’t check this in to a temporary
branch,
so can you add these lines to the run_tests.in file in gr-audio-osx/src?
Add them right after line 11 where the exec_prefix is set.
DYLD_LIBRARY_PATH="@abs_top_builddir@/gnuradio-core/src/lib/.libs"
export DYLD_LIBRARY_PATH
Jan–thanks for filing the bug.
-Johnathan
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 went OK except the initial configure.
I’m running a OSX PPC-Mac Dual G5 Desktop @ 2.0 GHz, latest OS, XCode
2.3.0.
Jan - Which Mac are you using (hardware, software, XCode)? It might
be that your shell environment is not configured correctly … I have
a specific shell which I use for all GNU Radio stuff, but it took me
a long time to work out just exactly what needs to be defined to most-
likely successful compilation and execution of GNU Radio - as found
in my OSX install guide. - MLD
On Thu, August 10, 2006 09:33, Michael D. 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 everything. So, at least for my
trial today, everything went OK except the initial configure.
The initial configure is designed to enable all the components that have
their dependencies satisfied. Do you in fact intend to compile for usrp
(and hench gr-usrp?)
If not (and thus you don’t have installed things like sdcc and libusb),
the above is the correct behavior.
Thanks for testing the new build, it looks like we can add your platform
to the list of successes.
There is a Wiki page at:
http://gnuradio.utah.edu/trac/wiki/MacInstall
…just waiting for your install guide 
-Johnathan
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 configure? I currently don’t.
The output of ./configure for me (just the tail) is appended. All
except the USRP ones are expected for my OS & installed libraries
(e.g. no portaudio, no comedi, no jack).
On Aug 10, 2006, at 12:43 PM, Johnathan C. wrote:
There is a Wiki page at:
http://gnuradio.utah.edu/trac/wiki/MacInstall
…just waiting for your install guide
I’ll get things there as soon as I reasonably can. Probably take a
couple of weeks. - MLD
The following GNU Radio components have been successfully configured:
config
gnuradio-core
gnuradio-examples
gr-audio-osx
gr-atsc
gr-error-correcting-codes
gr-gsm-fr-vocoder
gr-radar
gr-radio-astronomy
gr-video-sdl
gr-wxgui
pmt
gr-trellis
However, the following components did not configure successfully due to
missing dependencies:
usrp
gr-usrp
gr-audio-alsa
gr-audio-jack
gr-audio-oss
gr-audio-portaudio
gr-audio-windows
gr-comedi
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, August 10, 2006 09:55, Michael D. 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 have to have USRP hardware connected at
the time of configure? I currently don’t.
No. The build system for usrp checks for a number of things, but you
don’t need the hardware attached.
Look in:
http://gnuradio.utah.edu/svn/gnuradio/trunk/config/grc_usrp.m4
…to see the things that the usrp component looks for. These are
supposed to be the same things that were in the old configure.ac for
that
component, but of course I may have fubared it in the transition. Let
me
know if you see anything awry for your platform. Also capture the full
output of the configure script to see what it is reporting as a failure.
Thanks,
-Johnathan
Hmm … I don’t see anything obviously “wrong” or out of place w/
configure or the m4 script. Here’s the output of configure:
On Thu, August 10, 2006 10:13, Greg T. 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 just be ‘make dist’ and a single
tarball?
Er, yes. That is, until you sent this email.
(in a mutually exclusive and jointly exhaustive way).
From that point of view, it
would be nice to be able to enable and disable components and cause
configure to fail if the dependencies are not satisfied. The default
behavior if not given --enable-foo can of course be
build-if-prereqs-ok.
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:
What you’re suggesting is to have an --enable-foo and --disable-foo per
component. The --enable option would cause a build failure if
dependencies for that component were not satisfied. The --disable
option
would prevent that component from showing up in any make targets or
output. The default without specifying either would be to enable the
component if possible (current behavior.) I supposed you’d also need a
–disable-everything so you didn’t have to --disable one by one to build
a
single component.
This isn’t that hard, but touches a lot of things. There is also some
deep
voodoo going on to handle make check on a component when a dependent
component has not been installed yet (such as on a virgin
build/install.)
I have to think a bit on how to handle this.
-Johnathan
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
first
try, but my third machine is having a problem with the ecc.cc file. The
only
difference in the machines is that the two building successfully use gcc
3.4.6 and the machine failing is gcc 4.1.1. The list of errors being
generated is posted below.
(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 job
switching to Subversion. It’s working much nicer now.
Tom
g++ -DHAVE_CONFIG_H -I. -I. -I…/…/…
-I…/…/…/gnuradio-core/src/lib/runtime
-I…/…/…/gnuradio-core/src/lib/general
-I…/…/…/gnuradio-core/src/lib/general
-I…/…/…/gnuradio-core/src/lib/filter
-I…/…/…/gnuradio-core/src/lib/filter
-I…/…/…/gnuradio-core/src/lib/reed-solomon
-I…/…/…/gnuradio-core/src/lib/io
-I…/…/…/gnuradio-core/src/lib/g72x
-I…/…/…/gnuradio-core/src/lib/omnithread
-I…/…/…/gnuradio-core/src/lib/swig
-I…/…/…/gnuradio-core/src/lib/swig
-I/usr/include/python2.4 -g -O2 -Wall -Woverloaded-virtual -pthread -MT
ecc.lo -MD -MP -MF .deps/ecc.Tpo -c ecc.cc -fPIC -DPIC -o .libs/ecc.o
ecc.cc: In function ‘int SWIG_AsVal_bool(PyObject*, bool*)’:
ecc.cc:4465: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc:4468: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In function ‘PyObject*
_wrap_x_vector_ecc_streams_encode_convolutional_sptr_erase__SWIG_0(PyObject*
,
PyObject*)’:
ecc.cc:5936: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In function ‘PyObject*
_wrap_x_vector_ecc_streams_encode_convolutional_sptr_erase__SWIG_1(PyObject*
,
PyObject*)’:
ecc.cc:5978: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc:5989: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In function ‘PyObject*
_wrap_x_vector_ecc_streams_encode_convolutional_sptr_erase(PyObject*,
PyObject*)’:
ecc.cc:6025: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc:6038: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc:6042: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In function ‘PyObject*
_wrap_x_vector_ecc_streams_encode_convolutional_sptr_insert__SWIG_0(PyObject
,
PyObject)’:
ecc.cc:6381: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In function ‘PyObject*
_wrap_x_vector_ecc_streams_encode_convolutional_sptr_insert__SWIG_1(PyObject
,
PyObject)’:
ecc.cc:6434: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In function ‘PyObject*
_wrap_x_vector_ecc_streams_encode_convolutional_sptr_insert(PyObject*,
PyObject*)’:
ecc.cc:6482: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc:6499: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In function ‘PyObject*
_wrap_metrics_decode_viterbi_full_block(PyObject*, PyObject*)’:
ecc.cc:8581: error: conversion from ‘int’ to non-scalar type
‘std::vector<int, std::allocator >’ requested
ecc.cc: In function ‘PyObject*
_wrap_ecc_make_metrics_decode_viterbi_full_block_feedback(PyObject*,
PyObject*)’:
ecc.cc:8687: error: conversion from ‘int’ to non-scalar type
‘std::vector<int, std::allocator >’ requested
ecc.cc: In static member function 'static int
swig::traits_asptr_stdseq<Seq,
T>::asptr(PyObject*, Seq**) [with Seq =
std::vector<boost::shared_ptr<ecc_streams_encode_convolutional>,
std::allocator<boost::shared_ptr<ecc_streams_encode_convolutional> > >,
T =
boost::shared_ptr<ecc_streams_encode_convolutional>]’:
ecc.cc:4301: instantiated from 'static int
swig::traits_asptr<std::vector<pdf_fcn_io_t, std::allocator<_CharT> >
::asptr(PyObject*, std::vector<pdf_fcn_io_t, std::allocator<_CharT>
)
[with T = boost::shared_ptr<ecc_streams_encode_convolutional>]’
ecc.cc:3218: instantiated from 'int swig::asptr(PyObject, Type*)
[with
Type = std::vector<boost::shared_ptr<ecc_streams_encode_convolutional>,
std::allocator<boost::shared_ptr<ecc_streams_encode_convolutional> > >]’
ecc.cc:5137: instantiated from here
ecc.cc:4255: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In static member function 'static int
swig::traits_asptr_stdseq<Seq,
T>::asptr(PyObject*, Seq**) [with Seq = std::vector<int,
T>std::allocator
, T = int]’:
ecc.cc:4301: instantiated from 'static int
swig::traits_asptr<std::vector<pdf_fcn_io_t, std::allocator<_CharT> >
::asptr(PyObject*, std::vector<pdf_fcn_io_t, std::allocator<_CharT>)
[with T = int]’
ecc.cc:3218: instantiated from 'int swig::asptr(PyObject, Type*)
[with
Type = std::vector<int, std::allocator >]’
ecc.cc:6653: instantiated from here
ecc.cc:4255: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ecc.cc: In static member function ‘static int
swig::traits_asptr::asptr(PyObject*, Type**) [with Type =
boost::shared_ptr<ecc_streams_encode_convolutional>]’:
ecc.cc:3218: instantiated from ‘int swig::asptr(PyObject*, Type**)
[with
Type = boost::shared_ptr<ecc_streams_encode_convolutional>]’
ecc.cc:3340: instantiated from ‘static bool swig::traits_check<Type,
swig::pointer_category>::check(PyObject*) [with Type =
boost::shared_ptr<ecc_streams_encode_convolutional>]’
ecc.cc:3347: instantiated from ‘bool swig::check(PyObject*) [with Type
=
boost::shared_ptr<ecc_streams_encode_convolutional>]’
ecc.cc:3951: instantiated from 'bool
swig::PySequence_Cont::check(bool)
const [with T = boost::shared_ptr<ecc_streams_encode_convolutional>]’
ecc.cc:4243: instantiated from ‘static int
swig::traits_asptr_stdseq<Seq,
T>::asptr(PyObject*, Seq**) [with Seq =
std::vector<boost::shared_ptr<ecc_streams_encode_convolutional>,
std::allocator<boost::shared_ptr<ecc_streams_encode_convolutional> > >,
T =
boost::shared_ptr<ecc_streams_encode_convolutional>]’
ecc.cc:4301: instantiated from 'static int
swig::traits_asptr<std::vector<pdf_fcn_io_t, std::allocator<_CharT> >
::asptr(PyObject*, std::vector<pdf_fcn_io_t, std::allocator<_CharT>
)
[with T = boost::shared_ptr<ecc_streams_encode_convolutional>]’
ecc.cc:3218: instantiated from 'int swig::asptr(PyObject, Type*)
[with
Type = std::vector<boost::shared_ptr<ecc_streams_encode_convolutional>,
std::allocator<boost::shared_ptr<ecc_streams_encode_convolutional> > >]’
ecc.cc:5137: instantiated from here
ecc.cc:3208: warning: dereferencing type-punned pointer will break
strict-aliasing rules
make[6]: *** [ecc.lo] Error 1
On Thu, August 10, 2006 11:22, Michael D. 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
checking for byteswap.h… no
This is checked by:
AC_CHECK_HEADERS([byteswap.h],[],[succeeeded=no])
Any insight?
-Johnathan
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, August 10, 2006 11:36, Tom R. 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 job
switching to Subversion. It’s working much nicer now.
Please add this to ticket #25 on Trac:
http://gnuradio.utah.edu/trac/ticket/25
You’ll need to log in as ‘guest’ with password ‘gnuradio’ to modify the
ticket.
-Johnathan
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_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 I would expect it for my platform. Not sure
if those changes are really required, or maybe just on some
platforms? - MLD
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, August 10, 2006 12:20, Michael D. 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 I would expect it for my platform. Not sure
if those changes are really required, or maybe just on some
platforms? - MLD
The second line, by eliminating the second macro argument
[succeeded=no],
will prevent the component from being disabled even if this check fails,
so you’re just masking the problem. (Though I don’t know why it still
works.)
Either Matt or Eric wrote the original m4 macro checks. I need them to
confirm whether they still need all the function and header checks, and
whether those need to be different on different platforms.
-Johnathan
On Thu, August 10, 2006 11:52, Greg T. 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 sounds like it does this exactly.
So to build only gnuradio-core, you’d put
./configure --disable-all --enable-gnuradio-core
From the pkgsrc point of view, it’s ok to insist that a depending
component be either already installed where it belongs
or built in this build tree.
That will work. It’s only a ‘make check’ issue, not a compile issue.
For
example, if you wanted to create a gr-usrp package (that didn’t have
usrp
in it also), ‘make check’ would need to resolve the location of the
libusrp shared library. Since you’re not building usrp at the same
time,
and it might not be installed, ‘make check’ would fail. It wouldn’t
stop
you from building a package from the ‘make install’ output, but you
couldn’t put the ‘make check’ as part of the process.
It’s good to brainstorm this out because eventually we want to automate
the creation of .rpms and .debs and this issue will show up then too.
-Johnathan
On Aug 10, 2006, at 3:31 PM, Johnathan C. wrote:
platforms? - MLD
The second line, by eliminating the second macro argument
[succeeded=no],
will prevent the component from being disabled even if this check
fails,
so you’re just masking the problem. (Though I don’t know why it still
works.)
Yep, I know.
Either Matt or Eric wrote the original m4 macro checks. I need
them to
confirm whether they still need all the function and header checks,
and
whether those need to be different on different platforms.
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 function.
OSX does not implement this function for some reason (it does some of
the others in /usr/include/sched.h). Ah well, I guess no “real time”
for us OSX users for now.
I think it would be nice to not fail on this one, but rather to print
a warning about lacking real-time or whatever.
#ifdef HAVE_BYTESWAP_H
#include <byteswap.h>
#else
static inline unsigned short int
bswap_16 (unsigned short int x)
{
return ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8));
}
#endif
so, while this might not be the -best- method, it certainly works.
THis is the only reference in the USRP’s code to this include file.
I think Apple provides another function which does this, but I can’t
think of it right now. Likely as not, it does the same thing as this
code but with a different function name. - MLD
On Thu, August 10, 2006 12:43, Michael D. wrote:
for us OSX users for now.
I think it would be nice to not fail on this one, but rather to print
a warning about lacking real-time or whatever.
Ok, I can conditionalize this check so it doesn’t execute on your
platform. Please send me the output of the “config.guess” script on
your
machine.
- From host/lib/usrp_bytesex.h:34
#ifdef HAVE_BYTESWAP_H
#include <byteswap.h>
#else
I didn’t realize Matt provided an alternative if it wasn’t found, so in
fact your removal of the [succeeded=no] is appropriate.
-Johnathan
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs