Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Greg T. 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 that lists
autoconf/automake/libtool. Probably just add GNU make and note that
on systems where it isn’t native it is usually gmake (true of all BSDs
that I know of, and maybe Solaris).
We’ll note it in the README. Would you like to update the Wiki?
I’m building on NetBSD/i386 3.99.23 and will let you know of any other
issues.The next one is that the build (after doing a lot normally) ends up
with the following, which I haven’t looked into.I have python 2.4.3 and swig 1.3.29.
Those are all warnings, correct? The compile completes? What version
of gcc are you using?
-Johnathan
LRK wrote:
Best I can tell it all works. FreeBSD still has problems with the USB
code but the tests give the same errors as before. The audio part seems
to work as before also. I think I’m transitioned now.
Great!
If you’d like to document your experience, however briefly, you can edit
the Wiki page at:
http://gnuradio.utah.edu/trac/wiki/NetBSDInstall
You’ll need to login as ‘guest’ with password ‘gnuradio’ to be able to
edit.
-Johnathan
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Aug 10, 2006 at 08:16:57PM -0700, Johnathan C. wrote:
Greg T. 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 that lists
autoconf/automake/libtool. Probably just add GNU make and note that
on systems where it isn’t native it is usually gmake (true of all BSDs
that I know of, and maybe Solaris).
I’m working with FreeBSD and have been using gmake since there are still
problems with BSD make.
I’m installing as a user rather than with sudo. Seems to work Ok.
Best I can tell it all works. FreeBSD still has problems with the USB
code but the tests give the same errors as before. The audio part seems
to work as before also. I think I’m transitioned now.
–
LRK
[email protected]
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Aug 10, 2006 at 03:53:14PM -0400, Greg T. 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.
GNU make shouldn’t be required.
If there’s currently a “feature” which does require it, we’ll fix it.
Can you track down the offending line in the Makefile and/or
Makefile.am?
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/automake/libtool. Probably just add GNU make and note that
on systems where it isn’t native it is usually gmake (true of all BSDs
that I know of, and maybe Solaris).I’m building on NetBSD/i386 3.99.23 and will let you know of any other
issues.
Thanks!
The next one is that the build (after doing a lot normally) ends up
with the following, which I haven’t looked into.I have python 2.4.3 and swig 1.3.29.
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/pkg/include -I/usr/pkg/include/python2.3 -I. -I/usr/pkg/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT gnuradio_swig_python.lo -MD -MP -MF .deps/gnuradio_swig_python.Tpo -c gnuradio_swig_python.cc -fPIC -DPIC -o .libs/gnuradio_swig_python.o
gnuradio_swig_python.cc: In function ‘int SWIG_AsPtr_std_string(PyObject*, std::string**)’:
gnuradio_swig_python.cc:4604: warning: dereferencing type-punned pointer will break strict-aliasing rules
Which version of g++ ?
/var/tmp//ccWtqH2F.s: Assembler messages:
/var/tmp//ccWtqH2F.s:1447: Warning: .stabs: description field ‘1fa31’ too big, try a different debug format
/var/tmp//ccWtqH2F.s:1448: Warning: .stabs: description field ‘1fa36’ too big, try a different debug format
Can you try getting g++ to use dwarf2 instead of stabs?
Looks like NetBSD compiles g++ with stabs enabled as the default debug
format.
Eric
Greg T. wrote:
Thread model: posix
gcc version 4.1.2 20060628 prerelease (NetBSD nb2 20060711)
Please let me know where things stand with the latest trunk, and file a
bug on Trac so this issue doesn’t drop through the cracks.
-Johnathan
On Fri, Aug 11, 2006 at 04:49:00PM -0400, Greg T. wrote:
Also, ./configure fails to find py-wxWidgets because it invokes
‘python’, and NetBSD has only some of python2.3 and python2.4 (for 2.0
to 2.4). It seems the main python check works, so probably the py-wx
check should use something like ${PYTHON} instead. Even on systems
that have a default, this is scary because configure might have chosen
a non-default version (but maybe this can’t happen). My system has
2.3 and 2.4, and py24-wxWidggets. I can python2.4 and ‘import wx;’
with no errors.
This seems like a strange convention (no python, just python2.3,
python2.4, etc). What is the recommended magic to put at the top of
python scripts? We’ve been using “#!/usr/bin/env python”
Eric
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Sun, Aug 13, 2006 at 02:01:23PM -0700, Eric B. wrote:
This seems like a strange convention (no python, just python2.3,
python2.4, etc). What is the recommended magic to put at the top of
python scripts? We’ve been using “#!/usr/bin/env python”
FreeBSD does a hard link to the ‘latest’ version of such when using
the ‘ports’. It doesn’t do so for the autotools for whatever mysterious
reason. Probably something similar in NetBSD should set the default
version to use.
The python2.4 name is there for any programs needing a specific version.
–
LRK
[email protected]