Re: [Discuss-gnuradio] hanging on top_block.stop
You don't say what OS or version of boost you are using, but it sounds like an old problem. Try looking at http://lists.gnu.org/archive/html/discuss-gnuradio/2011-12/msg00098.html in the mailing list archives. -- Don W. - Original Message - From: Ben Reynwar b...@reynwar.net To: discuss-gnuradio Discussion Group discuss-gnuradio@gnu.org Sent: Tuesday, August 07, 2012 1:31 PM Subject: [Discuss-gnuradio] hanging on top_block.stop Hi all, The following script hangs for me about 1 time in 10 on the call to top_block.stop. Drilling in a bit, it appears to get stuck on a call to 'interrupt' of a boost::thread instance on line 91 of gruel/src/lib/thread_group.cc. Has anyone else had this problem? Cheers, Ben import time from gnuradio import gr def execute(): tb = gr.top_block() src = gr.vector_source_c([1], True) snk = gr.null_sink(gr.sizeof_gr_complex) tb.connect(src, snk) tb.start() time.sleep(0.01) print(**About to Stop***) tb.stop() print(**Stopped***) if __name__ == __main__: execute() ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR standard UHD options parser module (wasUHD default subdevice.)
LRK wrote: Make check seems to just hang when it gets here: gr-digital/python/qa_constellation_receiver.py Either this test takes more than 20 minutes or it is hung. Deleting this file allows the build and install to complete. This is a bug common to all versions; see: http://gnuradio.org/redmine/issues/471. It depends on the timing of execution, so it only fails sometimes, for some users on some machines with some operating systems. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio locking up
Matt Mills wrote:
Has anyone had time to look into the unlock() lockup that Rachel
reproduced
below further? I seem to be running into it left and right for some reason
and sadly my C++ isnt anywhere near good enough to go seeking the cause
myself.
This looks like an old boost problem
(https://svn.boost.org/trac/boost/ticket/2330). Is there any chance you are
using a version of boost older than 1.45?
-- Don W.
On Tue, Nov 22, 2011 at 9:02 AM, Rachel Kroll
rachelbythe...@gmail.comwrote:
On Nov 22, 2011, at 7:56 AM, Marcus D. Leech wrote:
On 22/11/11 10:48 AM, Rachel Kroll wrote:
It's pretty easy to get wedged forever if you call lock and unlock a
lot in conjunction with connect and disconnect. Sooner or later, you'll
hit a race and things will get stuck.
I have a simple reproduction case if anyone is interested. It'll hang
reliably after a few dozen iterations.
That's the type of information that shouldn't be withheld from this
list, and by implication, the
developers. Don't assume that because you've found a
bug/unexpected-behaviour, that the developers
know about it, and are working on a fix.
It's come up a few times in the mailing list archives. The usual
solution
seems to be add more sleeps, which of course is not a fix.
Anyway, here's the reproduction case:
#include gnuradio/gr_file_sink.h
#include gnuradio/gr_sig_source_f.h
#include gnuradio/gr_hier_block2.h
#include gnuradio/gr_io_signature.h
#include gnuradio/gr_top_block.h
static void connect(gr_top_block_sptr block, gr_sig_source_f_sptr source,
gr_hier_block2_sptr block2) {
fprintf(stderr, connect: calling lock, connect, unlock\n);
block-lock();
block-connect(source, 0, block2, 0);
block-unlock();
fprintf(stderr, connect: done\n);
}
static void disconnect(gr_top_block_sptr block, gr_sig_source_f_sptr
source,
gr_hier_block2_sptr block2) {
fprintf(stderr, disconnect: calling block-lock\n);
block-lock();
fprintf(stderr, disconnect: calling block-disconnect\n);
block-disconnect(source, 0, block2, 0);
fprintf(stderr, disconnect: calling block-unlock\n);
block-unlock(); // It usually hangs here.
fprintf(stderr, disconnect: done\n);
}
int main(int argc, char** argv) {
// Inner block: block to sink.
gr_hier_block2_sptr inner;
inner = gr_make_hier_block2(inner,
gr_make_io_signature(1, 1, sizeof(float)),
gr_make_io_signature(0, 0, 0));
gr_file_sink_sptr sink;
sink = gr_make_file_sink(sizeof(float), /dev/null);
inner-connect(inner, 0, sink, 0);
// Outer block: signal source to inner block.
gr_top_block_sptr outer = gr_make_top_block(outer);
gr_sig_source_f_sptr src = gr_make_sig_source_f(11025, GR_COS_WAVE,
400, .1, 0);
// Hook it up and get it going.
connect(outer, src, inner);
outer-start();
// Frob it until we die.
while (true) {
disconnect(outer, src, inner);
fprintf(stderr, \n\n\n\n);
connect(outer, src, inner);
}
return 0;
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] possible bug in gr_pfb_clock_sync_ccf.cc
Building gnuradio/master on Windows XP with MSVC++ 2010, I find that the test example qa_constellation_receiver_test hangs. Setting ENABLE_LOGGING in gr_block_executor.cc shows that gr_clock_sync_ccf's general_work() is being called repeatedly with noutput_items=1. But said general_work() only produces output for i noutput_items-d_osps, so it produces no output when noutput_items and d_osps are both equal to 1. This behavior occurs after the vector_source and all preceeding block have terminated. Not knowing exactly what gr_clock_sync_ccf is supposed to do and how it is supposed to work, I am having trouble debugging the problem further. Can anyone help? Thanks, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] cmake/MSVC build error (Windows XP)
While attempting to build GNU Radio (from git/master) on Windows XP with cmake and Visual C++ 2010 Express, I am getting: 4-- Build started: Project: gengen_generated_index, Configuration: Release Win32 -- [...] 4 Generating gengen/gengen_generated.i 4 4 The input line is too long. 4 C:\home\Don\gnuradio\build-msvc\gnuradio-core\src\libC:\Python27\python.exe -B C:/home/Don/gnuradio/build-msvc/gnuradio-core/src/lib/gengen/gengen_generated.py C:/home/Don/gnuradio/build-msvc/gnuradio-core/src/lib/gengen/gengen_generated.i C:/home/Don/gnuradio/build-msvc/gnuradio-core/src/lib/gengen/gr_vector_source_b.i [... most of single long line removed ...] C:/home/Don/gnuradio/build-msvc/gnuradio-core/src/lib/gengen/gr_peak 4C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: cmd.exe exited with code 255. This line appears in the file gengen_generated_index.vcxproj. I suppose it was put there by cmake. Any ideas on how to fix or work around this? I can shorten the path names by building in another directory, but that seems like an unappealing and temporary workaround at best. Thanks, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake/MSVC build error (Windows XP)
- Original Message - From: Josh Blum j...@ettus.com To: discuss-gnuradio@gnu.org Sent: Sunday, November 06, 2011 10:39 AM Subject: Re: [Discuss-gnuradio] cmake/MSVC build error (Windows XP) On 11/06/2011 06:16 AM, Don Ward wrote: While attempting to build GNU Radio (from git/master) on Windows XP with cmake and Visual C++ 2010 Express, I am getting: 4-- Build started: Project: gengen_generated_index, Configuration: Release Win32 -- [...] 4 Generating gengen/gengen_generated.i 4 4 The input line is too long. 4 C:\home\Don\gnuradio\build-msvc\gnuradio-core\src\libC:\Python27\python.exe -B C:/home/Don/gnuradio/build-msvc/gnuradio-core/src/lib/gengen/gengen_generated.py C:/home/Don/gnuradio/build-msvc/gnuradio-core/src/lib/gengen/gengen_generated.i C:/home/Don/gnuradio/build-msvc/gnuradio-core/src/lib/gengen/gr_vector_source_b.i [... most of single long line removed ...] C:/home/Don/gnuradio/build-msvc/gnuradio-core/src/lib/gengen/gr_peak 4C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: cmd.exe exited with code 255. This line appears in the file gengen_generated_index.vcxproj. I suppose it was put there by cmake. Any ideas on how to fix or work around this? I can shorten the path names by building in another directory, but that seems like an unappealing and temporary workaround at best. Can you pull master and try again? I actually way of generating it and merged the work. This was the make -j8 thread. That seems to fix it. Thanks (again!) for the amazing support. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make check errors in release candidate 3.5.0rc0
I have one or two errors in make check when building 3.5.0rc0 on Debian Linux (under VirtualBox on Windows XP): (1) in gr-trellis: make[7]: Entering directory `/home/don/gnuradio-3.5.0rc0/build-debian/gr-trellis/src/python' Traceback (most recent call last): File ../../../../gr-trellis/src/python/qa_trellis.py, line 32, in module import digital_swig ImportError: No module named digital_swig FAIL: run_tests It works ok if I add export PYTHONPATH after PYTHONPATH is set in gr-trellis/src/python/run_tests. (2) in gnuradio-core/src/python/gnuradio/gr: Ran 6 tests in 0.466s OK gr_vmcircbuf_sysv_shm: shmat (5): Invalid argument gr_buffer::allocate_buffer: failed to allocate buffer of size 64 KB .. -- Ran 2 tests in 3.042s OK .. -- Ran 2 tests in 0.007s OK ... -- Ran 3 tests in 0.013s OK PASS: run_tests It says OK and PASS despite the error messages. Is this normal? Thanks, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio and Uhd on windows,
Mark Colin wrote: When I power up the USRP1 it shows in the DeviceManager the LibUSB-Win32 Devices - USRP filter (VID=FFFE; PID=0004 Isn't LibUSB-Win32 the old libusb 0.1 driver? What happens if you uninstall the driver in the device manager and reinstall with the libusb 1.0 driver? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-audio: one component to rule them all
Josh Blum wrote:
On 03/29/2011 04:17 PM, Don Ward wrote:
Josh Blum wrote:
I have created a new top level component called gr-audio. The goal of
gr-audio is to combine all supported audio architectures under a single
source and sink block.
[snip...]
At runtime, an available audio architecture is selected.
This selection is based on default priority, or if present, a
configuration file setting.
Is there any way to specify in the code (e.g., through a command-line
option) which audio device to use?
There isnt, but, it would be conceivable to have an api call to set the
preferred architecture. Have you found a need for one?
(To be clear, I want to specify the architecture (alsa, portaudio,
windows, etc.), not the device name.)
For my applications, I have used
from gnuradio import audio_portaudio as audio
to get good results from any system I run them on, including the
temporary Cygwin and MinGW installations I use for testing. For
testing, it would be nice to be able to specify the architecture
to test on the command line of the test program.
With the new code, my only choice is to specify the architecture
in a file in my home directory, which is different for each
temporary installation Cygwin or MinGW. Also, it appears that I
can only set a preference and have no way of telling whether I am
actually using the architecture I asked for.
Could we have optional arguments to audio.{source,sink} to specify
the architecture (default=auto) and whether the specified
architecture is required or only preferred?
As an aside, I have never known where to find the documentation
for the configuration (or is it preferences?) file(s) (yes, I found
the info for gr-audio in the README file). Maybe we need a FAQ
entry telling about config.conf, common options, and what to search
for in the code for the less common options.
-- Don W.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-audio: one component to rule them all
Josh Blum wrote: I have created a new top level component called gr-audio. The goal of gr-audio is to combine all supported audio architectures under a single source and sink block. [snip...] At runtime, an available audio architecture is selected. This selection is based on default priority, or if present, a configuration file setting. Is there any way to specify in the code (e.g., through a command-line option) which audio device to use? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error while building wxPython
Vijay Pillai wrote: I am following the instructions at (Step 9) available at http://gnuradio.org/redmine/wiki/gnuradio/WxPythonCygwin In the previous step, I am able to generate the test window so I assume everything is working to that point. After running the following command python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 I get an error. I have tried various things such as use different versions of gcc without much success. I highly recommend picking one version of gcc and using that version only. If you switch versions, you should probably start over, recompiling everything. I also changed the ownership of directories as was noted in the tips section for installing on windows. The error that I get is attached at the end and seems to be related to gcc. What could be going wrong here? Error as follows - Vijay@DG70JBG1 /usr/src/wxPython-src-2.8.11.0/wxPython $ python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS =0 BUILD_GIZMOS=0 UNICODE=0 WARNING: WXWIN not set in environment. Assuming '..' Found wx-config: /usr/local/bin/wx-config Using flags: --toolkit=msw --unicode=no --version=2.8 Preparing CORE... Preparing STC... running build_ext building '_core_' extension gcc -mcygwin -mdll -O -Wall -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTP UT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DWXU SINGDLL -D__WXMSW__ -Iinclude -Isrc -I/usr/local/lib/wx/include/msw-ansi-release -2.8 -I/usr/local/include/wx-2.8 -I/usr/include/python2.6 -c src/helpers.cpp -o build/temp.cygwin-1.7.8-i686-2.6/src/helpers.o -O3 gcc: error trying to exec 'cc1plus': execvp: No such file or directory error: command 'gcc' failed with exit status 1 This seems to say that part of your gcc installation is missing. Use the command cygcheck -c to see what gcc is installed and to verify that the files required are present. Remove and reinstall any damaged packages. Remove any gcc/g++ versions other than the one you choose to use (only 3.4.4-999 is currently known to work with GNU Radio). Be prepared to rebuild any dependencies that you might have built with another compiler. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] aligned memory and posix_memalign
A worrisome (to me) issue with the volk library is the use of
posix_memalign() in the qa tests. The worry is:
* posix_memalign() will never work on Windows with Microsoft's runtime
library *
That means that code that uses posix_memalign won't work on Windows with
MinGW or Microsoft native compilers. (The problem is not that memory
alignment is difficult; it is simply that there is no memory-aligned version
of malloc() in the Microsoft API that works with free().)
At present, posix_memalign is used in GNU Radio in machine-dependent code
(gcell, altivec, and arm7) and in the volk qa tests. If we can replace it
in volk and avoid its spread, we can continue to use GNU Radio on Windows.
One option is to use something like malloc16Align/free16Align (in
malloc16.{h,c}) in gnuradio-core. Can we structure the code to make this
available in volk, and anywhere else it is needed? We can add a version to
do more general alignment if needed. Would it help to wrap aligned buffers
in a C++ class to make it easier to catch errors (such as using free() on a
malloc16Align() buffer)?
Note that simply enhancing our own missing/posix_memalign function using
_mingw_aligned_malloc() or Microsofts's _aligned_malloc() won't work because
memory allocated with those cannot be released with free().
Trying not to cause too much trouble,
-- Don W.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp/host build failure on MinGW
Build in usrp/host/misc is failing on MinGW with
tempname.c:315:4: error: too many arguments to function 'mkdir'
It appears that the MKDIR_TAKES_ONE_ARGUMENT logic has been removed from
config/{mkstmp,gr_pwin32}.m4.
Anyone know the right way to fix this?
-- Don W.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp/host build failure on MinGW
Josh Blum wrote:
On 03/06/2011 08:33 AM, Don Ward wrote:
Build in usrp/host/misc is failing on MinGW with
tempname.c:315:4: error: too many arguments to function 'mkdir'
It appears that the MKDIR_TAKES_ONE_ARGUMENT logic has been removed from
config/{mkstmp,gr_pwin32}.m4.
Anyone know the right way to fix this?
The mkdir stuff was replaced with boost filesystem calls. I must have
forgot to grep the random c files in the host code. Can you try the diff
attached?
Now it fails to find boost/filesystem/path.hpp. I think that BOOST_INCLUDES
needs to be a part of the g++ command.
-- Don W.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libstdc++ error on Cygwin
Vijay Pillai wrote: I am trying to install gnuradio on an XP machine under Cygwin. I followed all the instructions at http://gnuradio.org/redmine/wiki/gnuradio/CygwinInstallMain And ran the configure minimal system without any problems [...] When I run make, I get the following errors /usr/bin/grep: /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la: No such file or directorylibtoolL link: `/usr/lib/gcc/i686-pc-cygwin/4.3.2.libstdc++.la' is not a valid libtool archivemake[5]: *** [libgnuradio-core-qa.la] Error 1 What might be going wrong here? Someone wants gcc 4.3.2 libraries, but the Cygwin install instructions assume you are using gcc 3.4.4. Is it possible that you have installed cppunit 1.12.1 instead of 1.12.0? You need to be careful: Any updating of Cygwin packages will update cppupnit to 1.12.1 unless you specifically tell it not to in the Pending view of Cygwin setup. As an aside, it is helpful when reporting problems like this to show a little more of the output, including the libtool and g++ commands that preceded the error message. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libstdc++ error on Cygwin
Vijay Pillai wrote: Something that I want to note was that after running make check I did get an error message but the program did not halt when it showed the error. This error did not prevent the tone so maybe it does not matter. For reference, I am attaching the error message at the end of this mail. [...] Here is the error message at the end of running make check FAIL: run_tests == 1 of 1 test failed == Earlier in the output there should have been more information. The most likely problem would include the messages ...sem_init: No error and error: can't allocate lock This is a problem in Cygwin and does not indicate a problem in your GNU Radio installation. It does not always occur, and make check may succeed if you run it enough times. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error while installing portAudio
Vijay Pillai wrote: I followed the instructions at http://gnuradio.org/redmine/wiki/gnuradio/PortAudioInstall and am building under Cygwin. Everything works till the final make install. The error that i get is /usr/bin/install: cannot stat `./include/@INCLUDES@': No such file or director make: *** [install] Error 1. Would could I do to fix this? I ran into this myself just yesterday. The problem is that the PortAudio developers seem to be in the habit making snapshots with new versions of configure.in and Makefile.in but old versions of configure. The solution is run 'autoconf' in your portaudio directory before running ./configure. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] volk build issues on MinGW
Several minor issues and one major issue were encountered in building the
volk library on MinGW. The minor issues are:
(1) The use of symbolic links for volk/config.{sub,guess} is a problem. I
used a Cygwin version of git that produced Cygwin symlinks, which are
unusable in MinGW. A version of git exists for MSYS, but I'm not sure it
handles symbolic links. Is it possible to avoid using symbolic links in the
git repository?
(2) configure fails while testing for -lboost_unit_test_framework because
of the presence of -Wl,--enable-runtime-pseudo-reloc in LDFLAGS. I'm not
sure why it is a problem, but I don't think these flags are needed at all in
this situation. (Note: Cygwin had the same problem, and the solution used
there also works for MinGW.)
(3) volk/lib/testqa.cc requires the boost unit_test library. This needs to
be documented.
(4) boost/test/unit_test.hpp not found in volk/lib/testqa.cc: I think we
need to include $(BOOST_CPPFLAGS) in testqa_CPPFLAGS in
volk/lib/Makefile.am.
A big problem is that posix_memalign (used in the volk test program) will
never run on Windows. Given that aligned memory will be needed to use volk,
this becomes a major issue that will need to be addressed for future
development of GNU Radio. I will have further comment on this issue in a
separate thread.
-- Don W.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] volk build issues on Cygwin
Due mainly to circumstances beyond my control, it is now possible to build
the volk library on Cygwin :-). Previously, there was no support for C99
complex data types in the Cygwin library, but this was fixed by the release
of Cygwin 1.7.8-1 this past Tuesday.
The remaining issues can be addressed by patches or workarounds:
(1) configure fails while testing for -lboost_unit_test_framework because
of the presence of -Wl,--enable-runtime-pseudo-reloc in LDFLAGS. I'm not
sure why it is a problem, but I don't think these flags are needed at all in
this situation.
(2) C++ libraries are not found because
volk/config/gcc_version_workaround.m4 specifies -nostdinc++ without knowing
where to find the libraries on Cygwin. My suggestion is to exempt Cygwin
from the action of gcc_version_workaround.m4.
Changes to fix both of these (for Cygwin, anyway) are in the attached patch
file.
(3) volk_16i_x4_quad_max_star_16i_a16.h triggers an internal compiler error
in the Cygwin gcc 3.4.4-999. One workaround is to remove -O2 from the
Makefile. (An obvious suggestion is to use a newer compiler, but the last
time I tried it Cygwin gcc 4.x couldn't handle the exceptions generated
while looking for a working circular buffer strategy. I will check again
from time to time to see if the latest compiler works.)
The bottom line is that we can now build volk (and the GNU Radio 'next'
branch) on Cygwin.
-- Don W.
diff --git a/volk/config/gcc_version_workaround.m4
b/volk/config/gcc_version_workaround.m4
old mode 100644
new mode 100755
index b3ba0b6..3cd8a0c
--- a/volk/config/gcc_version_workaround.m4
+++ b/volk/config/gcc_version_workaround.m4
@@ -1,7 +1,11 @@
AC_DEFUN([LV_GCC_VERSION_WORKAROUND],
[
+case ${host_os} in
+ *cygwin*)
+ ;;
+ *)
AC_REQUIRE([LF_CONFIGURE_CXX])
cxx_version=`$CXX --version`
cxx_major_version=`echo $cxx_version | sed 's/[[^)]]*)
\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\).*/\1/'`
@@ -42,8 +46,8 @@ AC_DEFUN([LV_GCC_VERSION_WORKAROUND],
fi
-
+esac
])
\ No newline at end of file
diff --git a/volk/config/lv_configure.m4 b/volk/config/lv_configure.m4
old mode 100644
new mode 100755
index f98b2dc..dfa490c
--- a/volk/config/lv_configure.m4
+++ b/volk/config/lv_configure.m4
@@ -96,16 +96,17 @@ dnl AM_CONDITIONAL([USE_PYTHON], [test $with_python =
yes])
AC_HEADER_TIME
AC_C_BIGENDIAN
dnl Check for Mingw support
GR_PWIN32
- GR_LIBGNURADIO_CORE_EXTRA_LDFLAGS
+ dnl GR_LIBGNURADIO_CORE_EXTRA_LDFLAGS
dnl Check for liborc
ORC_CHECK
- LDFLAGS=$LDFLAGS $LIBGNURADIO_CORE_EXTRA_LDFLAGS
+ dnl Following causes test for -lboost_unit_test_framework to fail on Cygwin
+ dnl LDFLAGS=$LDFLAGS $LIBGNURADIO_CORE_EXTRA_LDFLAGS
AC_CHECK_PROG([XMLTO],[xmlto],[yes],[])
AM_CONDITIONAL([HAS_XMLTO], [test x$XMLTO = xyes])
dnl Define where to look for cppunit includes and libs
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The 'next' branch [MinGW]
Tom Rondeau wrote: I would ask all of you who can to start either using or at least testing out the 'next' branch now and provide us with feedback and bug reports. Two more issues with the 'next' branch: (1) It appears that the Boost 'system' and 'filesystem' modules are now required. This should be documented somewhere. (2) The Boost 'filesystem' module does not build on MinGW, because wstring is not supported in its libstdc++. I will look at the latest MinGW to see if this has changed. One possibility is to use an alternate C++ library (such as STLPort), but that sounds like a lot of work. An MSVC port is looking better all the time! -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The 'next' branch
Tom Rondeau wrote: I would ask all of you who can to start either using or at least testing out the 'next' branch now and provide us with feedback and bug reports. Compilation on Cygwin fails because there is no complex.h (#included by volk_complex.h) in Cygwin. In fact, there appears to be no support in the Cygwin C library for complex types (http://www.cygwin.com/cygwin-api/std-notimpl.html). (Complex numbers are supported in Cygwin's g++, however.) Unless there is some reasonable way to avoid requiring complex.h (or to avoid building volk), we will need to abandon GNU Radio under Cygwin. (That wouldn't bother me too much, as long as it works under MinGW---especially if support could be provided building with MSVC.) -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make errors in gnu radio 3.3.0 [cannot find -lboost_thread-gcc-mt-1_33_1]
Chomal, Sunil wrote: I removed boost 1.33.1.But now the errors have changed to below I tried using $ ./configure --disable-all-components --enable-gruel --enable-gnuradio-core --enable-gr-audio-oss --with-boost-include-dir=/usr/local/include/boost-1_45_0 Somehow boost 1.45.0 is not being use by the make Right; you need to look at the output of ./configure to find out why. $ make make all-recursive make[1]: Entering directory `/home/a0876473/gnuradio-3.3.0' Making all in config make[2]: Entering directory `/home/a0876473/gnuradio-3.3.0/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/a0876473/gnuradio-3.3.0/config' Making all in gruel make[2]: Entering directory `/home/a0876473/gnuradio-3.3.0/gruel' Making all in src make[3]: Entering directory `/home/a0876473/gnuradio-3.3.0/gruel/src' Making all in lib make[4]: Entering directory `/home/a0876473/gnuradio-3.3.0/gruel/src/lib' Making all in pmt make[5]: Entering directory `/home/a0876473/gnuradio-3.3.0/gruel/src/lib/pmt' make all-am make[6]: Entering directory `/home/a0876473/gnuradio-3.3.0/gruel/src/lib/pmt' make[6]: Nothing to be done for `all-am'. make[6]: Leaving directory `/home/a0876473/gnuradio-3.3.0/gruel/src/lib/pmt' make[5]: Leaving directory `/home/a0876473/gnuradio-3.3.0/gruel/src/lib/pmt' Making all in msg make[5]: Entering directory `/home/a0876473/gnuradio-3.3.0/gruel/src/lib/msg' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/a0876473/gnuradio-3.3.0/gruel/src/lib/msg' make[5]: Entering directory `/home/a0876473/gnuradio-3.3.0/gruel/src/lib' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded- virtual-o test_gruel.exe test_gruel.o pmt/libpmt-qa.la libgruel.la libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_gruel.exe test_gruel.o pmt/.libs/libpmt-qa.a -L/usr/lib /usr/lib/libcppunit.dll.a -ldl ./.libs/libgruel.a -lboost_thread-mt -lboost_thread-gcc-mt-1_33_1 /usr/lib/gcc/i686-pc-cygwin/4.3.4/libstdc++.dll.a -L/usr/lib/gcc/i686-pc-cygwin/4.3.4/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lboost_thread-mt/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lboost_thread-gcc-mt-1_33_1 Clearly, it still thinks that boost 1.33.1 is there, somewhere. But you need to examine the output of ./configure to find out what it found and where it found it. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make errors in gnu radio 3.3.0
Chomal, Sunil wrote: I am trying to build the gnu radio (release 3.3.0) for the first time on my windows pc. I am following the steps as in http://gnuradio.org/redmine/wiki/gnuradio/CygwinInstallMain I have installed cygwin and the relevant packages as mention in the above link. [...] I have installed boost in the directory \usr\src\boost_1_45_0 I tried setting the the environment variable LD_LIBRARY_PATH to this i.e export LD_LIBRARY_PATH=/usr/src/boost_1_45_0/libs You shouldn't need this. [...] libtool: link: rm -fr .libs/libgruel.dll.a libtool: link: g++ -shared -nostdlib /usr/lib/gcc/i686-pc-cygwin/4.3.4/crtbegin. o .libs/realtime.o .libs/sys_pri.o .libs/thread.o .libs/thread_body_wrapper.o . libs/thread_group.o -Wl,--whole-archive pmt/.libs/libpmt.a msg/.libs/libmsg.a - Wl,--no-whole-archive -L/usr/lib -lboost_thread-gcc-mt-1_33_1 -L/usr/lib/gcc/i6 The line above is looking for boost_thread-gcc-mt-1_33_1. Apparently ./configure is finding boost 1.33.1 instead of 1.45.0. Do you have the Cygwin boost 1.33.1 package installed? If so, try removing it. Then rerun ./configure and look at the output to see what version of boost is found. 86-pc-cygwin/4.3.4 -L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. /usr/lib/gcc/i68 6-pc-cygwin/4.3.4/libstdc++.dll.a -lgcc_s -lgcc_s -lcygwin -luser32 -lkernel32 - ladvapi32 -lshell32 -lgcc_s -lgcc_s /usr/lib/gcc/i686-pc-cygwin/4.3.4/crtend.o -O2 -o .libs/cyggruel-3-3-0-0.dll -Wl,--enable-auto-image-base -Xlinker --out- implib -Xlinker .libs/libgruel.dll.a Creating library file: .libs/libgruel.dll.a .libs/thread_group.o: In function `_ZN5boost12shared_mutex4lockEv': /usr/local/include/boost/thread/pthread/shared_mutex.hpp:129: undefined referenc e to `boost::this_thread::disable_interruption::disable_interruption()' [...] -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Windows status
Marcus D. Leech wrote: What is the status of GnuRadio, UHD, and GRC on Windows? I use GNU Radio (with USRP1 and wxgui) regularly on Windows with Cygwin and MinGW. I try to test new releases and keep the wiki instructions for building from tarballs up to date. I have not tried to build UHD, GRC, USRP2, or qtgui. Josh Blum recently reported that the core of GNU Radio can be built with native Microsoft tools, but an extra effort will be needed to include (and maintain) symbol import/export declarations in the code. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: How the valve block works
Patrick Strasser wrote: schrieb Josh Blum am 2011-01-08 05:29: Just found out that the selector block fits my requirements much better. But do I have the same behaviour here again? The valve is implemented with the selector. Thanks. What would be the best way to disable a branch of the flow graph, so that the disabled path is stopped/starved/drained/disabled? I do not care too much about stale data in buffers, I just want to get rid of the unnecessary processing power that is consumed by the path branch. If this is not possible in grc, I'd take the generated source and modify it, no big deal. Could you use a non-blocking message sink and a separate flow graph that takes input from a message source and is started and stopped as needed ? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] building gnuradio on windows with msvc
Josh Blum wrote: On 01/02/2011 08:21 AM, Moeller wrote: Hi Josh, isn't it easier with the GNU-Toolchain like Mingw (Windows native) or Cygwin (POSIX/Windows API)? For Cygwin there are lots of prebuilt packages and others build easily with ./configure ; make. Some need to be patched. Once I managed to get gnuradio running in Cygwin (X-windows) with GRC and did some live operations (waterfall, spectrum) with the soundcard. Unfortunately the latest SVN versions have some Boost and other errors and don't compile any more. The USRP2-drivers with raw socket interfaces didn't work, but with UHD and UDP-sockets this might be easier to realize. I don't have much experience with Mingw, but this gives you Windows native executables and is still very GNU-compatible. Usually I prefer Cygwin, but this gives you a lot of trouble when combining executables/DLLs from the Cygwin and native world (the exception handlers and runtime libs are not compatible). Well, lets assume you have to compile gnuradio stuff on windows. Its going to be painful. The question is, were should it hurt? If you put the burden on the code to be general enough to compile under a non-gnu compiler (MSVC here), then the end-developer will have an easier time, especially with the dependencies. Building the gnuradio dependencies from source, many needing patches, when your are already trying to build gnuradio... well its a world of pain to say the least. So, the burden on the code, means a burden on some developers to port components and periodically pull in the latest branch and test it, backport fixes. Thats why I ask, is anyone interested? Is it valuable lower the entry bar to gnuradio on windows? Because if not, the burden then falls back to the end-developer to setup a mingw/cygwin and build all the dependencies. I guess thats the way it is. mingw: I don't have much experience with mingw. From the wiki, it looks like you have to build all the deps from source. I tried once to get an environment setup and gave up in failure. Maybe its much better now. Can anyone with mingw experience weigh in? I use MinGW for my production GNU Radio system. It is a pain to gather and build the dependencies, but it's not as hard as it looks, and once it works it works forever. And if anyone is interested, I have a script to do all the work (posted twice, so far, in attachments to this list). Cygwin: I like thats its easy to install to get the useful command line tools, but building gnuradio + dependencies on it is just crazy hard. And its this pseudo-emulated environment. I don't know what that does for performance, but the gui apps don't look pretty. I did get grc working on it years back, then after some code overhaul, the python and gtk related packages were out of date for years. Can't mix dlls, cant use the pre-built gtk installer; no grc 4u :-) Cygwin is easier to get going, but Cygwin itself and the required dependencies make for a moving target with a continuously changing set of patches required to various packages. Speed doesn't seem to be an issue, apart from much slower builds (probably higher overhead to create a process). I haven't tried building qtgui, grc, usrp2, or uhd on either system, so I don't know what the issues are with these. I have never used MSVC, but given the choices I think it is worth pursuing. And I like the idea of being able to use the same build system on all platforms, though I can't comment on the practical aspects. Thanks, Josh, for doing this. Even if your changes are never incorporated in the main repository, I hope they can be stashed with your notes somewhere where the next person with the time and motivation to work on this can find them. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio make error
alirazib wrote: I have installed cygwin with all the required packages, and then installed boost, portaudio, SDCC and FFTW. WxPython could not be installed (WxWidgets was okay, but then error occurred during 'make'). Anyway, I thought WxPython is not absolutely vital for the initial experiments, so I left it like that. Then during the installation of gnuradio, I could configure (using command: ./configure --disable-all-components --enable-omnithread --enable-gruel --enable-gnuradio-core --enable-gr-audio-oss), but I am getting error during 'make': make all-recursive make[1]: Entering directory `/usr/src/gnuradio-3.3.0' Making all in config make[2]: Entering directory `/usr/src/gnuradio-3.3.0/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/gnuradio-3.3.0/config' Making all in gruel make[2]: Entering directory `/usr/src/gnuradio-3.3.0/gruel' Making all in src make[3]: Entering directory `/usr/src/gnuradio-3.3.0/gruel/src' Making all in lib make[4]: Entering directory `/usr/src/gnuradio-3.3.0/gruel/src/lib' Making all in pmt make[5]: Entering directory `/usr/src/gnuradio-3.3.0/gruel/src/lib/pmt' make all-am make[6]: Entering directory `/usr/src/gnuradio-3.3.0/gruel/src/lib/pmt' /bin/sh ../../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverload ed-virtual -no-undefined -avoid version -o libpmt-qa.la qa_pmt.lo qa_pmt_prim s.lo qa_pmt_unv.lo libpmt.la -lcppunit -ldl -lstdc++ -lwinmm /usr/bin/grep: /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la: No such file or d irectory This is caused by using Cygwin cppunit 1.12.1-1 (apparently compiled with gcc 4.3.2); use cppunit 1.12.0-1 instead (works with gcc 3.4.4). Can anyone suggest me what to do? I need to install USRP2 drivers after this step. And is WxPython really needed for simple experiments? I have updated the Cygwin installation instructions for wxPython and GNU Radio on the wiki. The important changes are: (1) don't use cppunit 1.12.1; (2) use Python 2.6 (instead of 2.5); (3) for wxPython 2.8.11.0 you don't need the patch that was used in 2.8.10, but you do need to patch Python 2.6 distutils. I have tested the new instructions (as far as the minium installation of gnuradio-3.3.0) and they work for me. If they don't work for you, send details of what doesn't work and we will see if we can fix it. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio make error
alirazib wrote: Thanks for your feedback. I have followed your suggestions to install a new cygwin with gcc 3.4.4 for gnuradio. Still WxPython could not be built. Step 9 ($ python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS =0 BUILD_GIZMOS=0 UNICODE=0) gives the following error: WARNING: WXWIN not set in environment. Assuming '..' [...] 3 [main] python 4516 C:\cygwin\bin\python.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\python2.6\lib-dynload\time.dll to same address as paren t: 0x26 != 0x34 Stack trace: Frame Function Args 002296E8 6102749B (002296E8, , , ) 002299D8 6102749B (61177B80, 8000, , 61179977) 0022AA08 61004AFB (611A136C, 6123F284, 0026, 0034) End of stack trace 3 [main] python 268 fork: child 4516 - died waiting for dll loading, errno 11 error: Resource temporarily unavailable This is a Cygwin (not wxPython) problem. Try a Google search on unable to remap. (I can't tell you how to fix it from personal experience since I haven't seen the problem myself.) then I tried to make gnuradio, but with the same error: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../.. -I/usr/local/include -I /usr/src/gnuradio-3.3.0/gruel/src/include -I/usr/src/gnuradio-3.3.0/gruel/src/in clude -g -O2 -Wall -Woverloaded-virtual -MT qa_pmt_unv.lo -MD -MP -MF .deps/qa_p mt_unv.Tpo -c qa_pmt_unv.cc -DDLL_EXPORT -DPIC -o .libs/qa_pmt_unv.o mv -f .deps/qa_pmt_unv.Tpo .deps/qa_pmt_unv.Plo /bin/sh ../../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverload ed-virtual -no-undefined -avoid version -o libpmt-qa.la qa_pmt.lo qa_pmt_prim s.lo qa_pmt_unv.lo libpmt.la -lcppunit -ldl -lstdc++ /usr/bin/grep: /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la: No such file or directory This is because you are using cppunit 1.12.1-1. If you use cppunit 1.12.0-1 you won't have this problem. You may need to start over on the GNU Radio installation after going back to 1.12.0-1. Hope this helps, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio make error
alirazib wrote: I have installed cygwin with all the required packages, and then installed boost, portaudio, SDCC and FFTW. WxPython could not be installed (WxWidgets was okay, but then error occurred during 'make'). Anyway, I thought WxPython is not absolutely vital for the initial experiments, so I left it like that. Then during the installation of gnuradio, I could configure (using command: ./configure --disable-all-components --enable-omnithread --enable-gruel --enable-gnuradio-core --enable-gr-audio-oss), but I am getting error during 'make': make all-recursive make[1]: Entering directory `/usr/src/gnuradio-3.3.0' Making all in config make[2]: Entering directory `/usr/src/gnuradio-3.3.0/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/gnuradio-3.3.0/config' Making all in gruel make[2]: Entering directory `/usr/src/gnuradio-3.3.0/gruel' Making all in src make[3]: Entering directory `/usr/src/gnuradio-3.3.0/gruel/src' Making all in lib make[4]: Entering directory `/usr/src/gnuradio-3.3.0/gruel/src/lib' Making all in pmt make[5]: Entering directory `/usr/src/gnuradio-3.3.0/gruel/src/lib/pmt' make all-am make[6]: Entering directory `/usr/src/gnuradio-3.3.0/gruel/src/lib/pmt' /bin/sh ../../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverload ed-virtual -no-undefined -avoid version -o libpmt-qa.la qa_pmt.lo qa_pmt_prim s.lo qa_pmt_unv.lo libpmt.la -lcppunit -ldl -lstdc++ -lwinmm /usr/bin/grep: /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la: No such file or directory It looks like someone is trying the find a library file associated with gcc 4.3.2. I have never seen 4.3.2 on Cygwin; I know that 4.3.4 has problems with GNU Radio but 3.4.4 worked the last time I tried it. What version of g++ are you using (i.e., what does g++ --version say)? What do you see when you say ls /usr/lib/gcc/i686-pc-cygwin? [...] Can anyone suggest me what to do? I need to install USRP2 drivers after this step. And is WxPython really needed for simple experiments? WxPython is really useful for visualizing what is happening, but is not absolutely required. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Windows Build environment -- Cygwin or MinGW?
Kevin Dixon wrote:
I'd like to get started building GNURadio for Windows, using the USRP
1, with the goal of writing some custom blocks. Do people prefer
Cygwin or MinGW style installations? Off the cuff, Cygwin looks more
straightforward. Any opinions?
I use GNU Radio (with USRP1) on both, but prefer MinGW as my production
environment.
Cygwin has more of the prerequisites available as easy-to-install packages,
but they change fairly often, and anytime you update to the latest packages
there is a risk that your next GNU Radio installation may not work. The
last time I tried it, they were in the process of moving from gcc 3.x to
4.x, but their gcc 4.x required some hacks to GNU Radio. At some point, I
expect that 3.x versions of the dependencies will no longer be available and
4.x will be the only option.
MinGW requires a little more work to get all the pieces together, but once
you have a working system it is more likely to continue to work forever.
Neither one is in any way comparable to your typical download-and-run
Windows install. It really helps if you have (or are willing to acquire)
some Unix/Linux experience, or are at least comfortable with using a Windows
cmd shell. I assume you have seen the instructions at
http://gnuradio.org/redmine/wiki/gnuradio/WindowsInstall.
I have attached a rudimentary Python script to install MinGW, MSYS, and GNU
Radio. You need to read the notes at the beginning of the script and edit
it to suit your needs, and you may need to updated the versions and/or
locations of the dependencies. But once you get it right, it could save you
a lot of work.
Good luck with it,
-- Don W.
# Install MinGw, MSYS, GNU Radio, and all it prerequisites (except python)
# on a Windows system.
#
# Python must be installed first in order to run this script. This version
# is based on the Python 2.6.5 Windows installer at
# http://www.python.org/download/
#
import os
import sys
import shutil
import urllib
import subprocess
#
# Install options
#
install_python_packages = True # wants admin privileges, but can do without
install_git = False # requires administrator privileges
install_mingw_and_msys = True
install_gr_prerequisites = False
install_gnuradio_tarball = False
install_gnuradio_git = False
option_usrp = True
option_portaudio = True
option_sdl_video = False # doesn't build
#
# Important locations
#
# Default is to install on drive containing Python executable
# If you override the default, you will need to check the install paths
# used by automated installers
install_drive = os.path.splitdrive(sys.executable)[0]
# install_drive = D: # override default here
# MinGW and MSYS locations
mingw_dir = install_drive+/MinGW
msys_dir = install_drive+/msys/1.0
# GNU Radio install directory
gr_inst_dir = msys_dir+/home/+os.environ['USERNAME']
local_src = msys_dir+/src
local_bin = msys_dir+/local/bin
local_dir = os.path.dirname( local_bin )
sh_env = os.environ
sh_env['PATH'] =
local_bin+;+mingw_dir+/bin;+msys_dir+/bin;+os.environ['PATH']
sh_env['MSYSTEM'] = MINGW32
sh_env['PKG_CONFIG_PATH'] = local_dir+/lib/pkgconfig
pyv = sys.version_info
py_vers = python%d.%d%pyv[0:2]
numpy_vers = 1.4.1
numpy_URL =
http://downloads.sourceforge.net/numpy/numpy-+numpy_vers+-win32-superpack-+py_vers+.exe;
# Python version
py_vers = py%d%d%pyv[0:2]
wxpython_vers = 2.8-win32-ansi-2.8.10.1
wxpython_URL =
http://downloads.sourceforge.net/wxpython/wxPython+wxpython_vers+-+py_vers+.exe;
wxpython_file = sys.exec_prefix+/Lib/site-packages/wxversion.py
sdcc_vers = 2.9.0
sdcc_file = install_drive+/Program Files/SDCC
sdcc_URL = http://downloads.sourceforge.net/sdcc/sdcc-+sdcc_vers+-setup.exe;
mingw_dl = http://downloads.sourceforge.net/mingw/;
mingw_URL = mingw_dl+MinGW-5.1.6.exe
msys_URL = mingw_dl+MSYS-1.0.11.exe
msys_vers = 'msys-1.0.11'
mingw_install_bin = (
'autoconf2.5-2.64-1',
'autoconf-7-1',
'automake1.11-1.11-1',
'automake-4-1',
'libtool-2.2.7a-1',
)
mingw_install_dll = (
)
msys_install_bin = (
'perl-5.6.1_2-1',
'm4-1.4.13-1',
'guile-1.8.7-1',
'patch-2.5.9-1',
)
msys_install_dll = (
('libcrypt-1.1_1-2',0),
('libguile-1.8.7-1',17),
('libgmp-4.3.1-1',3),
('libltdl-2.2.7a-1',7),
('libregex-1.20090805-1',1),
)
msys_install_rtm = (
'libguile-1.8.7-1',
)
xemacs_exe = install_drive+/Program
Files/XEmacs/XEmacs-21.4.22/i586-pc-win32/xemacs.exe
unzip_prog = unz600xn
unzip_file = unzip_prog+.exe
unzip_URL = ftp://ftp.info-zip.org/pub/infozip/win32/+unzip_file
unzip_exe = unzip.exe
glib_file = glib_2.24.0-2_win32.zip
glib_URL = http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.24/+glib_file
gnome_URL_deps = http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/;
pkgconfig_file = pkg-config_0.23-3_win32.zip
pkgconfig_URL = gnome_URL_deps+pkgconfig_file
swig_version = swigwin-1.3.40
swig_file = swig_version+.zip
swig_URL =
Re: [Discuss-gnuradio] Unable to compile under MinGW in a directoryoutside MSYS
Jimmy Richardson wrote: On 11/6/2010 2:38 AM, Don Ward wrote: Jimmy Richardson wrote: I got latest MinGW installed and I'm trying to compile latest GNURadio based on the steps from http://gnuradio.org/redmine/wiki/gnuradio/MingwInstallMain, everything works if I put the gnuradio source files under /usr/src/gnuradio, however if I run ./bootstrap and ./configure from outside MSYS directory system, say E:\gnuradio (i.e. change directory to /e/gnuradio inside MSYS) and run ./bootstrap and ./configure, then make, I got error: test_gruel.cc: In function 'void ensure_unittest_path(const char*, const char*)' : test_gruel.cc:75:3: error: 'mkdir' was not declared in this scope make[5]: *** [test_gruel.o] Error 1 Is there a ./configure flag I should use in this case? My guess is that this is due to a recent change in gruel/src/lib/test_gruel.cc. Try adding the line #include unistd.h immediately after the line #include sys/stat.h Please let us know if this works. It did get rid of the original error, but I got a new one now: test_gruel.cc: In function 'void ensure_unittest_path(const char*, const char*)' : test_gruel.cc:76:3: error: too many arguments to function 'int mkdir(const char*)' c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/io.h:302:3 7: note: declared here test_gruel.cc:77:3: error: too many arguments to function 'int mkdir(const char* )' c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/io.h:302:3 7: note: declared here make[5]: *** [test_gruel.o] Error 1 I can see the following in config.log: configure:19611: checking whether mkdir accepts only one arg configure:19628: gcc -c -DWINVER=0x0501 -I/usr/local/include conftest.c 5 configure:19628: $? = 0 configure:19629: result: yes Aha! In gruel/src/lib/test_gruel.cc, try adding the line #include config.h before the line #include cppunit/TextTestRunner.h Let us know if that fixes it. Thanks, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unable to compile under MinGW in a directoryoutside MSYS
Jimmy Richardson wrote: I got latest MinGW installed and I'm trying to compile latest GNURadio based on the steps from http://gnuradio.org/redmine/wiki/gnuradio/MingwInstallMain, everything works if I put the gnuradio source files under /usr/src/gnuradio, however if I run ./bootstrap and ./configure from outside MSYS directory system, say E:\gnuradio (i.e. change directory to /e/gnuradio inside MSYS) and run ./bootstrap and ./configure, then make, I got error: test_gruel.cc: In function 'void ensure_unittest_path(const char*, const char*)' : test_gruel.cc:75:3: error: 'mkdir' was not declared in this scope make[5]: *** [test_gruel.o] Error 1 Is there a ./configure flag I should use in this case? My guess is that this is due to a recent change in gruel/src/lib/test_gruel.cc. Try adding the line #include unistd.h immediately after the line #include sys/stat.h Please let us know if this works. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Does anybody have sucessfully installed GNURadio on Windows
Matt Dunstan wrote: OK, I really don't know what to do with that GNU Radio. I tried to install it many times with CygWin and MinGW but no success, this is why I have this question: does anybody have sucessfully installed GNU Radio on Windows OS Yes, I have installed it on Windows many times using both Cygwin and MinGW, and run it on Windows routinely. (on the site of Ettus Research it's written: it works under Win 7, XP ...)? or maybe everybody is working under Linux and I shouldn't try to install GNU Radio on Windows because I waste my time as I did in the last 3 month. Have you followed the instructions at http://gnuradio.org/redmine/wiki/gnuradio/CygwinInstallMain or http://gnuradio.org/redmine/wiki/gnuradio/MingwInstallMain? Have you asked for help? It is true that both Cygwin and MinGW and the required third-party libraries can change over time and cause things to stop working, but if you report problems to this list someone will try to help. Best regards, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio build on cygwin failed with usrp
Kyle Zhou wrote: Updated git repository on my cygwin(1.7.7-1)+winxp box this weekend and tried rebuild gnuradio ./configure reported usrp is not to be built due to not able to detect libusb I do have libusb-win32 0.1.12.2-1 in cygwin Looked at the config.log, I found it insists on checking pkgconfig file libusb.pc, which does not exist. I manually created that file. Then it goes a bit further. [...] configure:25136: checking libusb for symbol usb_debug in library usb configure:25150: gcc -o conftest.exe -I/usr/include conftest.c -lusb 5 /tmp/ccaJXA3I.o:conftest.c:(.text+0x2c): undefined reference to `_usb_debug' It appears that this was broken (for Cygwin) in the latest git commit (ddbb914d) of config/usrp_libusb.m4. My copy of libusb-win32 0.1.12.2-1 does not have the symbol usb_debug in either the .h file or the shared library. Could someone review the change to usrp_libusb.m4 and see if it could be made to function again under Cygwin? Or explain why the change was made so someone else (like me?) can suggest an alternative? In the meanwhile you can work around the problem by modifying config/usrp_libusb.m4 to omit the check for usb_debug then rerunning ./bootstrap. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question GNU Radio swig Path
Matt Dunstan wrote: i have a question related to GNU Radio installation. I followed all steps described in http://gnuradio.org/redmine/wiki/1/MingwInstallMain, but when I want to install gnuradio 3.3.0 it says that it can't find swig. It finds python becasue it is decalred in Environment Variables under Path with the value of C:\Python26. Swig is installed under C:\msys\1.0\local\swigwin-1.3.40, the problem is that I don't know how I sould declare the swig path and where. The step that says export PATH=$PATH:/c/Python26:/usr/local/swigwin-1.3.40:/c/Progra~1/SDCC/bin should take care of this. Another option is to create a file called /usr/local/bin/swig with the commands: #! /bin/sh exec 'C:/msys/1.0/local/swigwin-1.3.40/swig.exe' $@ Make the file executable with chmod +x /usr/local/bin/swig. In any case, the command which swig should tell you whether swig can be found. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] what is latest stable release?
It has been a while since gnuradio-3.3.0 was sent out as a release candidate, but the Download page on the wiki still points to gnuradio-3.2.2. Is there a reason not to use 3.3.0 or is the wiki just out of date? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building gnuradio on cygwin - wxPython issue
Jan Schiefer wrote:
I should know better, but I am nonetheless trying to build gnuradio on
Windows XP/cygwin. I did follow the instructions on the wiki (including
picking the exact versions), but I am getting stuck on building
wxPython.
. . .
While I try to keep GNU Radio running under Cygwin, every update to a
Cygwin package or third-party library (such as wxPython) carries a
significant risk of breakage. For production use of GNU Radio on
Windows, I prefer to use MinGW and MSYS. The initial setup takes a
little longer, but once you have a working system there is seldom a need
to update anything but GNU Radio.
. . .
Thanks Don, this is good advice, I have been hit by cygwin update-related
breakages for other applications as well. I will try the MinGW/MSYS route
instead and report back.
I have attached a python script I used to install GNU Radio on MinGW/MSYS.
It has only basic error checking and no documentation, but you may find it
helpful. If nothing else, it lists the version numbers and file locations
of all the pieces. To use it, read the start of the script and edit the
install options and location as needed. Let me know if you find it useful.
-- Don W.
# Install MinGw, MSYS, GNU Radio, and all it prerequisites (except python)
# on a Windows system.
#
# Python must be installed first in order to run this script. This version
# is based on the Python 2.6.5 Windows installer at
# http://www.python.org/download/
#
import os
import sys
import shutil
import urllib
import subprocess
#
# Install options
#
install_python_packages = True # wants admin privileges, but can do without
install_git = False # requires administrator privileges
install_mingw_and_msys = True
install_gr_prerequisites = True
install_gnuradio_tarball = True
install_gnuradio_git = False
option_usrp = True
option_portaudio = True
option_sdl_video = False # doesn't build
#
# Important locations
#
# Default is to install on drive containing Python executable
# If you override the default, you will need to check the install paths
# used by automated installers
install_drive = os.path.splitdrive(sys.executable)[0]
# install_drive = D: # override default here
# MinGW and MSYS locations
mingw_dir = install_drive+/MinGW
msys_dir = install_drive+/msys/1.0
# GNU Radio install directory
gr_inst_dir = msys_dir+/home/+os.environ['USERNAME']
local_src = msys_dir+/src
local_bin = msys_dir+/local/bin
local_dir = os.path.dirname( local_bin )
sh_env = os.environ
sh_env['PATH'] =
local_bin+;+mingw_dir+/bin;+msys_dir+/bin;+os.environ['PATH']
sh_env['MSYSTEM'] = MINGW32
sh_env['PKG_CONFIG_PATH'] = local_dir+/lib/pkgconfig
pyv = sys.version_info
py_vers = python%d.%d%pyv[0:2]
numpy_vers = 1.4.1
numpy_URL =
http://downloads.sourceforge.net/numpy/numpy-+numpy_vers+-win32-superpack-+py_vers+.exe;
# Python version
py_vers = py%d%d%pyv[0:2]
wxpython_vers = 2.8-win32-ansi-2.8.10.1
wxpython_URL =
http://downloads.sourceforge.net/wxpython/wxPython+wxpython_vers+-+py_vers+.exe;
wxpython_file = sys.exec_prefix+/Lib/site-packages/wxversion.py
sdcc_vers = 2.9.0
sdcc_file = install_drive+/Program Files/SDCC
sdcc_URL = http://downloads.sourceforge.net/sdcc/sdcc-+sdcc_vers+-setup.exe;
mingw_dl = http://downloads.sourceforge.net/mingw/;
mingw_URL = mingw_dl+MinGW-5.1.6.exe
msys_URL = mingw_dl+MSYS-1.0.11.exe
msys_vers = 'msys-1.0.11'
mingw_install_bin = (
'autoconf2.5-2.64-1',
'autoconf-7-1',
'automake1.11-1.11-1',
'automake-4-1',
'libtool-2.2.7a-1',
)
mingw_install_dll = (
)
msys_install_bin = (
'perl-5.6.1_2-1',
'm4-1.4.13-1',
'guile-1.8.7-1',
'patch-2.5.9-1',
)
msys_install_dll = (
('libcrypt-1.1_1-2',0),
('libguile-1.8.7-1',17),
('libgmp-4.3.1-1',3),
('libltdl-2.2.7a-1',7),
('libregex-1.20090805-1',1),
)
msys_install_rtm = (
'libguile-1.8.7-1',
)
xemacs_exe = install_drive+/Program
Files/XEmacs/XEmacs-21.4.22/i586-pc-win32/xemacs.exe
unzip_prog = unz600xn
unzip_file = unzip_prog+.exe
unzip_URL = ftp://ftp.info-zip.org/pub/infozip/win32/+unzip_file
unzip_exe = unzip.exe
glib_file = glib_2.24.0-2_win32.zip
glib_URL = http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.24/+glib_file
gnome_URL_deps = http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/;
pkgconfig_file = pkg-config_0.23-3_win32.zip
pkgconfig_URL = gnome_URL_deps+pkgconfig_file
swig_version = swigwin-1.3.40
swig_file = swig_version+.zip
swig_URL = http://prdownloads.sourceforge.net/swig/+swig_file
fftw_version = fftw-3.2.2
fftw_dir = local_src+/+fftw_version
fftw_file = fftw_version+.tar.gz
fftw_URL = http://www.fftw.org/+fftw_file
cppunit_version = cppunit-1.12.0# 1.12.1 fails make check (05/02/08)
cppunit_dir = local_src+/+cppunit_version
cppunit_file = cppunit_version+.tar.gz
cppunit_URL=http://downloads.sourceforge.net/cppunit/+cppunit_file
boost_numbers = (1,43,0)
boost_version = boost_%d_%d_%d%boost_numbers
boost_dir = local_src+/+boost_version
Re: [Discuss-gnuradio] Building gnuradio on cygwin - wxPython issue
Jan Schiefer wrote: I should know better, but I am nonetheless trying to build gnuradio on Windows XP/cygwin. I did follow the instructions on the wiki (including picking the exact versions), but I am getting stuck on building wxPython. When I try to do the python setup.py install WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 step, I get the following error: function Traceback (most recent call last): File setup.py, line 1034, in module **other_kw File /usr/lib/python2.6/distutils/core.py, line 152, in setup dist.run_commands() File /usr/lib/python2.6/distutils/dist.py, line 975, in run_commands self.run_command(cmd) . . . File /usr/lib/python2.6/distutils/cygwinccompiler.py, line 189, in link libraries.extend(self.dll_libraries) TypeError: 'NoneType' object is not iterable The offending line 189 is a rather nondescript libraries.extend(self.dll_libraries) Has anybody who is more pythonic than me seen this before? My cygwin version is current as of last Wednesday, and the python version is 2.6.5 (no other python installations on the machine). The problem is a Cygwin-specific error in the Python release. A patch (for /usr/lib/python2.6/distutils/cygwinccompiler.py) is attached. I haven't done a complete install with the latest Cygwin, but I have found several things to watch out for: (1) As noted in the wiki, GNU Radio does not work with gcc4 (4.3.4); use gcc (3.4.4) instead. (2) The latest cppunit (1.12.1-1) only works with gcc4; use 1.12.0-1 instead. (3) Do not try to use the Cygwin libboost* packages; they not only require gcc4, but will install gcc4 and make it the default. Build boost from source as described in the wiki. In general, it appears that Cygwin is moving away from supporting gcc 3.x. I will follow up on the issue that is preventing GNU Radio from working with gcc4 (on Cygwin) and hope it can be resolved before support for gcc 3.x (on Cygwin) is removed. -- Don W. cygwinccompiler.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building gnuradio on cygwin - wxPython issue
Jan Schiefer wrote: I should know better, but I am nonetheless trying to build gnuradio on Windows XP/cygwin. I did follow the instructions on the wiki (including picking the exact versions), but I am getting stuck on building wxPython. When I try to do the python setup.py install WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 step, I get the following error: function Traceback (most recent call last): File setup.py, line 1034, in module **other_kw File /usr/lib/python2.6/distutils/core.py, line 152, in setup dist.run_commands() File /usr/lib/python2.6/distutils/dist.py, line 975, in run_commands self.run_command(cmd) ... File /usr/lib/python2.6/distutils/ccompiler.py, line 769, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File /usr/lib/python2.6/distutils/cygwinccompiler.py, line 189, in link libraries.extend(self.dll_libraries) TypeError: 'NoneType' object is not iterable The offending line 189 is a rather nondescript libraries.extend(self.dll_libraries) Has anybody who is more pythonic than me seen this before? My cygwin version is current as of last Wednesday, and the python version is 2.6.5 (no other python installations on the machine). My latest test install of Cygwin and GNU Radio (May 2010) used python 2.5.5. You could try going back to that version. I will try to look at it over the weekend and see if I can make it work with 2.6.5. While I try to keep GNU Radio running under Cygwin, every update to a Cygwin package or third-party library (such as wxPython) carries a significant risk of breakage. For production use of GNU Radio on Windows, I prefer to use MinGW and MSYS. The initial setup takes a little longer, but once you have a working system there is seldom a need to update anything but GNU Radio. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-howto-write-a-block configure error incygwin
Kyle Zhou wrote: ... I am playing howto-write-a-block in cygwin. Git trunk. ... After that, 'make' succeeded. But when I do 'make check', making check in lib succeeded, but when checking in python, it produced an error as follows. Making check in python make[1]: Entering directory `/home/kyle/gnuradio/gr-howto-write-a-block/python' make check-TESTS make[2]: Entering directory `/home/kyle/gnuradio/gr-howto-write-a-block/python' /home/kyle/gnuradio/gr-howto-write-a-block/lib:/home/kyle/gnuradio/gr-howto-writ e-a-block/lib/.libs:/home/kyle/gnuradio/gr-howto-write-a-block/swig:/home/kyle/g nuradio/gr-howto-write-a-block/swig/.libs:/home/kyle/gnuradio/gr-howto-write-a-b lock/python:/usr/local/lib/python2.5/site-packages:/usr/local/lib/python2.5/site -packages:/usr/local/lib/python2.5/site-packages/ Traceback (most recent call last): File ./qa_howto.py, line 24, in module import howto_swig File /home/kyle/gnuradio/gr-howto-write-a-block/swig/howto_swig.py, line 21, in module import _howto_swig ImportError: No such file or directory FAIL: run_tests I just ran into this. The problem is that the directory (swig/.libs) containing cyggnuradio-howto-0.dll (libgnuradio-howto-0.dll on MinGW) needs to be in your PATH variable. This setup is done in run_tests.sh for the main GNU Radio, but there is no analogous setup in run_tests for howto-write-a-block. I will work on this tomorrow (unless someone else does it first). Does anyone know if OSX has the same problem? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc0 available for testing
Johnathan Corgan wrote: GNU Radio release 3.3.0-rc0 is available for testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc0.tar.gz Builds smoothly on Cygwin after replacing ltmain.sh in tarball with ltmain.sh from git repository. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc0 available for testing
Johnathan Corgan wrote: GNU Radio release 3.3.0-rc0 is available for testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc0.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc0.tar.gz This is the first release candidate for the 3.3 release series. This builds and runs on MinGW/MSYS except that it has the same problem as the 3.3git-594 tarball: The supplied version of ltmain.sh does not handle interlibrary dependencies on Windows. I have attached a diff file showing the slight differences between the ltmain.sh in the tarball (2.2.6b Debian-2.2.6b-2ubuntu1, which fails) and the ltmain.sh downloaded from packages.debian.org (plain 2.26b). It looks like it was broken in Ubuntu 2.2.6a-3 (change log says Don't pull in depedency libs when linking a binary). GNU Radio builds ok if I run ./bootstrap locally. It would be nice if we could ship a tarball with a ltmain.sh that works on Windows. -- Don W. P.S.: I have brought the MinGW install page on the wiki up to date (I hope to add instructions for git soon). ltmain.sh.diff Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] thread safety of gr_wavfile_sink::close()
I have a question about the thread safety of gr_wavfile_sink::close(). The description says it is thread safe and it uses d_mutex, but what is to stop the work() function from writing the file at the same time that close() (via close_wav()) is writing and closing the file? gr_wavfile_sink::work() does not lock d_mutex (except when d_updated is set). Is there something going on behind the scenes to prevent the threads from mangling the output file, or is this a problem with the code? The reason I am interested is because I would like to do something similar with gr_udp_sink, allowing one socket to be closed and a new one to be created when one client finishes and another client starts up. Thanks, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close()
- Original Message - From: Eric Blossom e...@comsec.com To: Don Ward don2387w...@sprynet.com Cc: gnuradio mailing list discuss-gnuradio@gnu.org Sent: Friday, April 30, 2010 8:25 PM Subject: Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close() On Fri, Apr 30, 2010 at 07:42:32PM -0400, Don Ward wrote: I have a question about the thread safety of gr_wavfile_sink::close(). The description says it is thread safe and it uses d_mutex, but what is to stop the work() function from writing the file at the same time that close() (via close_wav()) is writing and closing the file? gr_wavfile_sink::work() does not lock d_mutex (except when d_updated is set). Is there something going on behind the scenes to prevent the threads from mangling the output file, or is this a problem with the code? The reason I am interested is because I would like to do something similar with gr_udp_sink, allowing one socket to be closed and a new one to be created when one client finishes and another client starts up. Thanks, -- Don W. It looks fairly hosed up. One fundamental design/documentation problem is that the header file does not document which variables must be protected by the mutex. Also, proper use of the mutex (including in work) would eliminate all of the code related to d_updated. So, it is ok to use the mutex across the work function? While I'm at it, set_bits_per_sample quietly fails for any value not equal to 8 or 16. gr_udp_sink has similar problems. Ok. Let me work on gr_udp_sink, then you can tell me how close I came to getting it right. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP source block in GRC
- Original Message - From: Eric Blossom e...@comsec.com To: Marcus D. Leech mle...@ripnet.com Cc: GNURadio Discussion List discuss-gnuradio@gnu.org Sent: Thursday, April 22, 2010 6:24 PM Subject: Re: [Discuss-gnuradio] UDP source block in GRC On Fri, Apr 09, 2010 at 10:23:43PM -0400, Marcus D. Leech wrote: I'm trying to use a UDP source block from a GRC-produced flowgraph. The only thing it does is this: gr_block_executor: source gr_block udp_source (2) produced no output. We're marking it DONE. The udp source/sink needs an overhaul. This error is triggered to indicate that the block (a source) is returning zero, and thus is most likely spinning. Whatever overhauling is done, it would nice to have the option of treating zero-bytes-read from gr_udp_souce as an EOF condition. A client can then decide whether to wait for a server or give up. (It might also be nice to have program access to the timeout value.) -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fix for usrp2 overruns when stopping andrestarting rx streaming
Andy_Long wrote: I have tried to build from source. However, after sudo make install there is always a error that, Do I miss some some dependencies? I have install all the package with similar name from documents here. http://gnuradio.org/redmine/repositories/changes/gnuradio/README Error message: deps/usrp2_impl.Tpo -c usrp2_impl.cc -fPIC -DPIC -o .libs/usrp2_impl.o usrp2_impl.cc: In member function ‘void usrp2::usrp2::impl::start_bg()’: usrp2_impl.cc:340: Error： ‘bind’isn't‘boost’member I ran into this also a day or two ago. Try adding #include boost/bind.hpp to usrp2/host/include/usrp2/usrp2.h. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Make error
Ms reena vade wrote: The following are the lines where I am getting the error message when I type $make: usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/bits/stl_algo.h:68, from /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/algorithm:67, from realtime.cc:33: built-in: In function `std::pair_Tp*, int std::get_temporary_buffer(ptrdiff_t)': built-in:0: error: too many arguments to function `void* operator new(unsigned int)' /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/bits/stl_tempbuf.h:100: error: at this point in file make[3]: *** [realtime.lo] Error 1 make[3]: Leaving directory `/cygdrive/f/gnuradio-3.2.2/gnuradio-3.2.2/gruel/src/lib' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/cygdrive/f/gnuradio-3.2.2/gnuradio-3.2.2/gruel/src' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/cygdrive/f/gnuradio-3.2.2/gnuradio-3.2.2/gruel' make: *** [check-recursive] Error 1 The last time I checked (about 5 weeks ago), GNU Radio did not work with gcc 4.3.4 in Cygwin. Try using gcc 3.4.4 instead (as suggested in the wiki). -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installing GNURadio on Cygwin, Windows XP: URGENT!!!!!!!!!!!!!
Ms reena vade wrote: Hello everyone! I am new to GNURadio. I tried installing cygwin with all the utilities and libraries as given on gnuradio.org. And then I unzipped gnuradio as well. I have the following doubts: ( 1 ) Shall I unzip GNURadio in the same drive where I have installed cygwin? For Eg : i have downloaded cygwin and installed it on my F :\ drive. And on the same drive I have unzipped GNURadio-3.2.2. So my question is shall I unzip GNURadio inside cygwin or I am ok if it is installed on F : drive? It shouldn't matter as long as there are no spaces in your path name. ( 2 ) If the answer of above question is that I let GNURadio remain on F drive, then when I try building the minimal GNURadio syatem by giving the ./configure command, i get error: unable to use python headers. How to solve this? I assume you are following the instructions at gnuradio.org/redmine/wiki/gnuradio/CygwinInstallMain. If not you may want to look there first. The config.log file tells you what it was doing when it ran into trouble. Does the file /usr/include/python2.5/Python.h exist? It might help to tell us what parameters you used on ./configure and the exact error message and the lines that precede it in the output of ./configure. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test tarballs for 3.3git
Johnathan Corgan wrote: Test tarball distribution files have been created for the current 3.3git release under development: http://gnuradio.org/releases/gnuradio/gnuradio-3.3git-594-g02616cf8.tar.gz Apart from one or two minor issues, this tarball works fine under Cygwin 1.7.1 with gcc 3.4.4, but with gcc 4.3.4 make check fails with ~/gnuradio-3.3git-594-g02616cf8/gnuradio-core/src/tests ./test_all.exe Testing gr_vmcircbuf_createfilemapping_factory... ... gr_vmcircbuf_createfilemapping_factory: OK Testing gr_vmcircbuf_sysv_shm_factory... terminate called after throwing an instance of 'gr_signal' Aborted (core dumped) It appears that a signal is being caught and a gr_signal is being thrown but not caught. This is probably a Cygwin-specific problem with exception handling in gcc 4.3.4, but if anyone else has seen problems like this and has any insight as to the cause, I would like to hear about it. Thanks, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usleep problem while executing make forgnuradio-3.1.3 on MSYS-MINGW
Shabbir Ahmed wrote: I have been trying to get GNURADIO installed on windows, failed with CYGWIN and then tried with MSYS/MINGW everything went fine until the last, while executing make for gnuradio. --- $ make make all-recursive make[1]: Entering directory `/usr/src/gnuradio-3.1.3' Making all in config make[2]: Entering directory `/usr/src/gnuradio-3.1.3/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/config' Making all in omnithread make[2]: Entering directory `/usr/src/gnuradio-3.1.3/omnithread' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -DOMNITHREAD_NT=1 -DPthreadDraftVersion=10 -I/usr/src/gnuradio-3.1.3/omnithread -I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -MT omni_time.lo -MD -MP -MF .deps/omni_time.Tpo -c -o omni_time.lo omni_time.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -DOMNITHREAD_NT=1 -DPthreadDraftVersion=10 -I/usr/src/gnuradio-3.1.3/omnithread -I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -MT omni_time.lo -MD -MP -MF .deps/omni_time.Tpo -c omni_time.cc -DDLL_EXPORT -DPIC -o .libs/omni_time.o In file included from omni_time.cc:23: ../config.h: In function `int nanosleep(const timespec*, timespec*)': ../config.h:467: error: `usleep' was not declared in this scope ../config.h:467: warning: unused variable 'usleep' make[2]: *** [omni_time.lo] Error 1 make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/omnithread' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gnuradio-3.1.3' make: *** [all] Error 2 - It is a problem that was reported earlier ( http://old.nabble.com/Make-fail...config.h:467:-error:-'usleep'-was-not-declared-in-this-scope-td21246741.html) but no solution is posted in the link. I looked into the steps mentioned by Don. But couldnt get any leads. This problem (and others) are fixed in the latest development version (the git repository). I recommend that you install git under Cygwin and use that to download the latest code (per http://gnuradio.org/redmine/wiki/gnuradio/Download). You could also start with the 3.2.2 tarball (is there a reason you are using 3.1.3?) and add patches, but many of the quick patches (when done right) are more than simple hand edits and require that you run ./bootstrap before they will take effect. For example, you can fix the usleep problem above by adding #include unistd.h before the call to usleep in config.h, but that fix will go away the next time you run ./configure; patching config.h.in will fix that, but the right way is to patch config/gr_pwin32.m4 and rerun ./bootstrap and ./configure. In any case, you will need the following: * Before ./configure: export CXX=g++ -mthreads export LDFLAGS=-L/usr/local/lib -lws2_32 If you want to try patching problems in 3.2.2: * If using Python 2.5, after running ./configure edit Makefile to add -shrext .pyd to PYTHON_LDFLAGS * In config.h and config.h.in, add #include unistd.h before the call to usleep * In gnuradio-core/src/lib/missing, edit Makefile to remove references to posix_memalign * In gnuradio-core/src/lib/io, remove references to gr_histo_sink in Makefile.* and io.i * use --disable-gr-msdd6000 on ./configure * If building usrp code, add #include config.h near top of usrp/host/lib/db_wbxng.cc I hope this helps. Eventually, this will all be documented in the wiki, but until then feel free to ask when you run into problems. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error installing wxPython on CYGWIN in Windows XP
Shabbir Ahmed wrote: A. Managed to install and work wxWidgets but I just cannot manage wxPython. Anyhow the following is how I managed wxWidgets and errors found in trying to install wxPython. B. Referring to http://gnuradio.org/redmine/wiki/gnuradio/WxPythonCygwin STEP 4: ( I had to add a few more lines that I took from wxPython's src website http://www.wxpython.org/BUILD.html .. so now we have) CC=gcc -mno-cygwin -mwindows \ CXX=g++ -mno-cygwin -mwindows \ LDFLAGS=-mno-cygwin -mwindows \ The -mno-cygwin option says to create a native Windows version rather than a Cygwin version, which gets around the winsock.h vs. select.h problem. But it is not clear whether a non-Cygwin extension will work with the Cygwin version of Python. ../configure \ --with-msw \ --build=i686-pc-mingw32 \ --prefix=/usr/local \ STEP 4a, 5 and 6: Remains the same. STEP 7: (there is slight change the cygwx*.dll files are now wx*.dll files.. so we have) mv /usr/local/lib/wx*.dll /usr/local/bin STEP 8: so now when you try step 8 it WORKS! STEP 9: (But now I am stuck in STEP 9 and cannot move forward tried all possibilities the following is the code I am using and the output+errors...) python setup.py build_ext --inplace WXPORT=msw COMPILER=mingw32 BUILD_GLCANVAS=0 BUILD_ACTIVEX=0 UNICODE=0 WX_CONFIG=bash.exe -e /usr/local/bin/wx-config OUTPUT+ERROR WARNING: WXWIN not set in environment. Assuming '..' Preparing CORE... Preparing STC... Preparing GIZMOS... running build_ext building '_core_' extension gcc -mno-cygwin -mdll -O -Wall -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTPUT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -DWXUSINGDLL -D__WXMSW__ -Iinclude -Isrc -I/usr/local/lib/wx/include/msw-ansi-release-2.8 -I/usr/local/include/wx-2.8 -I/usr/include/python2.5 -c src/helpers.cpp -o build/temp.cygwin-1.7.1-i686-2.5/src/helpers.o -mthreads -O3 In file included from /usr/include/python2.5/Python.h:57, from src/helpers.cpp:15: /usr/include/python2.5/pyport.h:257:24: sys/select.h: No such file or directory Your Cygwin version of Python wants to use select.h, which doesn't exist in you non-Cygwin (i.e., -mno-cygwin) environment. Again, I don't know if it is possible to build non-Cygwin extensions for a Cygwin Python. The good news is that this problem has been reported on the wxWidgets bug tracker and is being worked on (see http://trac.wxwidgets.org/ticket/11626). The bad news, is that the supposed correct answer is to modify the code (if possible) to use posix networking calls in place of the Windows calls. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error installing wxPython on CYGWIN in Windows XP
Shabbir Ahmed wrote: i. Down to business I am having errors in installing wxPython on CYGWIN in Windows XP. ii. Have been referring to http://gnuradio.org/redmine/wiki/gnuradio/WxPythonCygwin for installation guide. iii. In the above, Steps 1, 2, 3, 4 and 4a works like a charm, I am still attaching the output files in case you need to refer to them. iv. In Steps 5 i get the following warnings and error: In file included from ../src/msw/utils.cpp:56: /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api/winsock.h:479: error: declaration of C function ‘int select(int, _types_fd_set*, _types_fd_set*, _types_fd_set*, const timeval*)’ conflicts with /usr/include/sys/select.h:31: error: previous declaration ‘int select(int, _types_fd_set*, _types_fd_set*, _types_fd_set*, timeval*)’ here As Bob McGwier reported to the list on 3 Jan, there has been a major update to Cygwin, including a switch to gcc 4.3.4. I don't know if anyone has tried to install GNU Radio with the new version and I know that the instructions in the wiki have not been updated for the the new version. The immediate problem is that both winsock.h and select.h have been included, leading to a conflict. You may be able to avoid this by editing build-local/lib/wx/include/msw-ansi-release-2.8/wx/setup.h so that HAVE_SYS_SELECT_H is undefined. Of course this might just be the first of many such errors that are not easily fixed. Another possibility is that another include file in gcc 4.3.4 is including select.h. If that is the case, we will need to see what can be done. It should be noted that the latest Cygwin FAQ states you can't use winsock functions in Cygwin (even though the winsock.h header file is included in the distribution). So they may have changed it so it just won't work. Checking out the new Cygwin is on my list of things to do, but it probably won't happen soon. Please let us know what you find. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Parser error when building gnuradio under Cygwin
radio...@covad.net wrote: I am attempting to build gnuradio under cygwin and everything seems to go fine, with the exception of the documentation for the usrp. unfortunately this shuts down the make so that it never completes. Any guidance as to what I might be missing or file changes that would enable this to complete the make process would be appreciated. Thanks, -CAS . . . make[4]: Entering directory `/usr/src/gnuradio-3.2.2/usrp/doc' xmlto html-nochunks ../../usrp/doc/usrp_guide.xml xmlto: input does not validate (status 1) http://www.oasis-open.org/docbook/xml/4.2/:1: parser error : Content error in the external subset !DOCTYPE html ^ http://www.oasis-open.org/docbook/xml/4.2/:1: parser error : Content error in the external subset !DOCTYPE html ^ This is a known problem with xmlto on Cygwin (see http://gnuradio.org/trac/wiki/WindowsTips). The solution is to remove or disable xmlto, or modify the Makefile so to bypass the building of the documentation. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building wxPython in Cygwin
radio...@covad.net wrote:
I am attempting to build wxPython under Cyqwin. Like the message posted on
the listserv September 14, I am getting an error message for a missing
CreateBitmap member in the class wxGraphicsRenderer. The complete output
from build step 9 showing all of the error messages follows at the end of
this message. I made the modifications to both the setup.h file and the
timer.cpp files as indicated in the build instructions and the
_gdi_wrap.cpp file as suggested in the previous e-mail. The output below
indicates that I still am seeing the same problem even with the updated
files. I have included snips from both setup.h and _gdi_wrap.cpp with the
modifications in the event that I either entered the information
incorrectly or that there is another problem in the file that I have
missed. The widgets installed fine and run the test cases without a
problem, so I would appreciate any suggestions as to where to go from here
to complete the wxPython build.
Thanks,
-CAS
File: Setup.h (starting at line 320)
#define wxUSE_COMBOBOX 1
#define wxUSE_DATAVIEWCTRL 0
#define wxUSE_DATEPICKCTRL 1
#define wxUSE_DATEPICKCTRL_GENERIC 1
#define wxUSE_DIRPICKERCTRL 1
#define wxUSE_FILEPICKERCTRL 1
#define wxUSE_FONTPICKERCTRL 1
#define wxUSE_GAUGE 1
#define wxUSE_HYPERLINKCTRL 1
File: _gdi_wrap.cpp (starting at line 4055)
virtual wxGraphicsBrush CreateRadialGradientBrush( wxDouble xo, wxDouble
yo,
wxDouble xc,
wxDouble yc, wxDouble radius,
const wxColour
oColor, const wxColour cColor) { return wxNullGraphicsBrush; }
virtual wxGraphicsFont CreateFont( const wxFont , const wxColour )
{ return wxNullGraphicsFont; }
/* Next line added per per web message regarding installation: CAS -
11/27/2009 */
virtual wxGraphicsBitmap CreateBitmap ( const wxBitmap ) { return
wxNullGraphicsBitmap; }
This line was added in the wrong place; it should be added at about line
4156. The instructions at http://gnuradio.org/trac/wiki/wxPythonCygwin
include a patch that does this for you.
wxGraphicsBitmap CreateBitmap( const wxBitmap bitmap ) const { return
wxNullGraphicsBitmap; }
-- Don W.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about build GNU Radio
Li Mei-Wen wrote: Becasue I got error about GNU Radio on USRP in /../digital So, I try to install the GNU Radio again When I do the make check (Building a Full GNU Radio System from http://gnuradio.org/trac/wiki/CygwinInstallMain) I got follow error message What can I do? [snipped] .. gr_fir_ccc: using SSE .sem_init: Resource temporarily unavailable E.. == ERROR: test_ccc_005 (__main__.test_fft_filter) -- Traceback (most recent call last): File ./qa_fft_filter.py, line 157, in test_ccc_005 expected_result = reference_filter_ccc(dec, taps, src_data) File ./qa_fft_filter.py, line 51, in reference_filter_ccc tb.run() File /usr/src/gnuradio-3.2/gnuradio-core/src/python/gnuradio/gr/top_block.py , line 104, in run self.wait() File /usr/src/gnuradio-3.2/gnuradio-core/src/python/gnuradio/gr/top_block.py , line 107, in wait _top_block_waiter(self._tb).wait() File /usr/src/gnuradio-3.2/gnuradio-core/src/python/gnuradio/gr/top_block.py , line 56, in __init__ _threading.Thread.__init__(self) File /usr/lib/python2.5/threading.py, line 409, in __init__ self.__block = Condition(Lock()) error: can't allocate lock -- Ran 6 tests in 1.781s FAILED (errors=1) This looks very much like an error mentioned in the wiki (on the page you referenced above). Does it always occur in the same place? Have you tried running in a different shell, or logging off and back on? If the error doesn't always occur or if it occurs at different places in the test sequence, it is probably the error discussed in the wiki. I find it does not usually cause problems in normal use. The only way I know to avoid it is to patch Python and rebuild it from source. -- Don W. [snipped] FAIL: run_tests == 1 of 1 test failed == make[6]: *** [check-TESTS] Error 1 make[6]: Leaving directory `/usr/src/gnuradio-3.2/gnuradio-core/src/python/gnura dio/gr' make[5]: *** [check-am] Error 2 make[5]: Leaving directory `/usr/src/gnuradio-3.2/gnuradio-core/src/python/gnura dio/gr' make[4]: *** [check-recursive] Error 1 make[4]: Leaving directory `/usr/src/gnuradio-3.2/gnuradio-core/src/python/gnura dio' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/usr/src/gnuradio-3.2/gnuradio-core/src/python' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/usr/src/gnuradio-3.2/gnuradio-core/src' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/usr/src/gnuradio-3.2/gnuradio-core' make: *** [check-recursive] Error 1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about Bui lding wxPython in Cygwin
Li Mei-Wen wrote: When I do the setp (9) (http://gnuradio.org/trac/wiki/wxPythonCygwinon windows) python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 I get sfollowing error message. What can I do? administra...@888tiger-452d27 /usr/src/wxPython-src-2.8.10.1/wxPython $ python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS =0 BUILD_GIZMOS=0 UNICODE=0 WARNING: WXWIN not set in environment. Assuming '..' Found wx-config: /usr/local/bin/wx-config Using flags: --toolkit=msw --unicode=no --version=2.8 Preparing CORE... Preparing STC... running build_ext building '_controls_' extension writing build/temp.cygwin-1.5.25-i686-2.5/src/msw/_controls_.def g++ -mcygwin -shared -s build/temp.cygwin-1.5.25-i686-2.5/src/msw/_controls_wrap .o build/temp.cygwin-1.5.25-i686-2.5/src/msw/_controls_.def -L/usr/local/lib -L/ usr/lib/python2.5/config -lwx_msw_richtext-2.8 -lwx_msw_aui-2.8 -lwx_msw_xrc-2.8 -lwx_msw_qa-2.8 -lwx_msw_html-2.8 -lwx_msw_adv-2.8 -lwx_msw_core-2.8 -lwx_base_ xml-2.8 -lwx_base_net-2.8 -lwx_base-2.8 -lpython2.5 -o wx/_controls_.dll build/temp.cygwin-1.5.25-i686-2.5/src/msw/_controls_wrap.o:_controls_wrap.cpp:(. text+0xce4e8): undefined reference to `__imp___ZTV23wxDatePickerCtrlGeneric' [snipped] Did you make the change to setup.h described in step (4)? Note: In versions 2.8.8.1, 2.8.9.1, and 2.8.10.1 you will need to find the file build-local/lib/wx/include/msw-ansi-release-2.8/wx/setup.h and after the line: #define wxUSE_DATEPICKCTRL 1 add another line: #define wxUSE_DATEPICKCTRL_GENERIC 1 before going to the next step. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about Bui lding GNU Radio System in Cygwin
Li Mei-Wen wrote: When I building a Full GNU Radio System (http://gnuradio.org/trac/wiki/CygwinInstallMain on windows) $ cd gnuradio-3.2 $ ./configure I get following error message. And I saw the other discuss, I also did the ./configure --prefix=$BOOST_PREFIX --with-libraries=thread,date_time,program_options on boost_1_36_0.. http://osdir.com/ml/discuss-gnuradio-gnu/2009-07/msg00098.html In the above in boost 1.36 on Cygwin it is mentioned,$ ./configure --with-libraries=thread,date_timefor the configure command. But while configuring I ended up with the following errorconfigure: error: Could not link against libboost_program_options!The solution to this problem is to use the following as a configure cmd.$ ./configure --prefix=$BOOST_PREFIX --with-libraries=thread,date_time,program_options But had the same error message... Did you repeat the make, make install, and cp steps for installing boost? Are the libboost_program_options files listed when you do ls /usr/local/lib/*boost*? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about Bui lding wxPython in Cygwin
Li 美文 wrote:
When I do the setp (9) (http://gnuradio.org/trac/wiki/wxPythonCygwin on
windows)
python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin
BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0
I get sfollowing error message.
What can I do?
[snipped]
gcc -mcygwin -mdll -O -Wall -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTP
UT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-DWXU
SINGDLL -D__WXMSW__ -Iinclude -Isrc -I/usr/local/lib/wx/include/msw-ansi-release
-2.8 -I/usr/local/include/wx-2.8 -I/usr/include/python2.5 -c
src/msw/_gdi_wrap.c
pp -o build/temp.cygwin-1.5.25-i686-2.5/src/msw/_gdi_wrap.o -O3
[warnings snipped]
src/msw/_gdi_wrap.cpp: In function `PyObject*
_wrap_GraphicsRenderer_CreateBitma
p(PyObject*, PyObject*, PyObject*)':
src/msw/_gdi_wrap.cpp:32226: error: 'class wxGraphicsRenderer' has no
member nam
ed 'CreateBitmap'
In wxPython/src/msw/_gdi_wrap.cpp, after the line
virtual wxGraphicsFont CreateFont( const wxFont , const wxColour ) {
return wxNullGraphicsFont; }
you need to add the line
virtual wxGraphicsBitmap CreateBitmap( const wxBitmap ) { return
wxNullGraphicsBitmap; }
-- Don W.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems with GNU radio in Cygwin
Robert Pegram wrote: I am installing GNUradio version 3.2 into Cygwin running Windows XP. I am using the tarball source for wxPython version 2.8.10.1. I have unpacked the source and successfully compiled it, built and installed wxWidgets, built and installed wxPython and tested it successfully. I did have to copy the python2.5/site-packages from /usr/lib/local to /usr/local/lib/python2.5/site-packages. I then continued with the 3.2 install of GNUradio. I had to get and install the 1.38 version of Boost. I unpacked the the tarball for GNUradio 3.2 and ran the following commands in the /usr/src/gnuradio-3.2 directory to perform an full installation of GNUradio: ./configure make make check make install. I received some warnings but no errors and the setup and install completed. When I cd my working directory to gnuradio-examples/python/audio to run the test audio program is when I received the following error: cd /gnuradio-examples/python/audio python dial_tone.py Traceback (most recent call last): File dial_tone.py, line 23, in module from gnuradio import gr ImportError: No module named gnuradio By default, python looks in /usr/lib/python2.5/site-packages for a directory called gnuradio. Is it there? To find where your build put gnuradio, run the command fgrep pythondir config.status in your build directory and look at the value of pythondir. Does it say /usr/lib or /usr/local/lib? Is gnuradio there? If gnuradio is in /usr/local/lib/python2.5/site-packges, did you set PYTHONPATH? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems with GNU radio in Cygwin
Robert Pegram wrote: I have the python2.5 site-packages installed in both /usr/lib and /usr/local/lib directories. Which one contains the directory gnuradio? Which PYTHONPATH should be used? The one that contains gnuradio. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HELP: about Building wxPython in Cygwin
Li 美文 emily7...@hotmail.com wrote: Thank for your help... Yes, it can works. But, When setp (9) Build wxPython: cd $WXDIR/wxPython python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 I get following error message What can I do? em...@ncku-34be181a97 /usr/src/wxPython-src-2.8.10.1/wxPython $ python setup.py build_ext --inplace WXPORT=msw BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 src/helpers.cpp: In member function `void wxPyInputStream::seek(int, int)': src/helpers.cpp:1340: error: `m_wxis' undeclared (first use this function) src/helpers.cpp:1341: error: `wxSeekMode' undeclared (first use this function) src/helpers.cpp: In member function `int wxPyInputStream::tell()': src/helpers.cpp:1345: error: `m_wxis' undeclared (first use this function) src/helpers.cpp: In constructor `wxPyCBInputStream::wxPyCBInputStream(PyObject*, PyObject*, PyObject*, bool)': src/helpers.cpp:1354: error: class `wxPyCBInputStream' does not have any field n amed `wxInputStream' src/helpers.cpp: At global scope: src/helpers.cpp:1410: error: `wxFileOffset' does not name a type . . . Did you include COMPILER=cygwin in your command (I don't see it in the listing above)? There are a lot of errors here, and I don't know what caused them. You may need to do your own debugging. (To get you started, it looks like m_wxis is defined in pyistream.h, which is included in helpers.cpp.) Or you might start with a new download, in case one or more files got corrupted. I didn't get these errors when I built wxPython 2.8.10.1 on Cygwin, but it is possible that you are using newer compilers or other Cygwin components. Good luck, and let us know what you find. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] regarding gnuradio-3.2rc0.tar.gz installation onwindows XP
john boon wrote: i have been following the mails and going through mail lists, couldnt find any information which can point me whether installation of gnuradio-3.2rc0.tar.gz is possible on windows XP. I have installed 3.2rc2 on Windows XP using Cygwin. The instructions in the wiki should be very close to accurate, with only minor tweaks needed when the 3.2 release is finalized. I did not build the usrp2, comedi, sdl, or qtgui modules. The inband code does not link properly on Cygwin, but this does not stop the build of the rest of the code. gnuradio-3.2rc2 does not build on MinGW because of the new requirement for an aligned malloc() function. I expect this will be fixed, or you can work around it. Again, I think the instructions in the wiki are pretty close. i have been successfull in installing gnuradio-3.2rc0.tar.gz on FEDORA 10 and subsequently i tried on windows XP, where it threw results of successfull configuration of usrp and few components and not the required gr-usrp,gr-utils,usrp2 and other main components. Whereas with same boost instlation of version 38, i was able to install gnuradio-3.1.3.tar.gz. in brief, successfull installation of gnuradio-3.1.3.tar.gz possible on windows XP not the gnuradio-3.2rc0.tar.gz. My question based on the above results. 1. can gnuradio-3.2rc0.tar.gz be installed on the windows. has anyone tried in this regard and succeeded ?? Yes and yes, with Cygwin, and it should be possible in time (or with more work) on MinGW. I have no information on other build environments. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mingw linker cannot find -lsocket
Zainab Qureshi: When i enter the 'make' command for gnuradio i get the following error. configure:20701: checking for socket in -lsocket configure:20736: gcc -o conftest.exe -g -O2 -Wall conftest.c -lsocket 5 C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lsocket collect2: ld returned 1 exit status Can anyone help me in finding the solution to the problem? This looks like the normal contents of config.log. (It is looking to see if -lsocket is present on your system; it isn't, and that's normal for MinGW.) It would be very odd for this to be displayed on the screen when you run 'make'. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installing GNU Radio with MinGW and MSYS ¶
Zainab Qureshi wrote: I am trying to install the gnuRadio with minGW and MSYS on windows xp professional with sp3. I have follwed the steps given on this link http://gnuradio.org/trac/wiki/MingwInstallMain However when i write this command cd gnuradio-3.1.3 ./configure --prefix=C:/msys/1.0/local i get the following error checking for usleep... (cached) yes checking for gettimeofday... (cached) yes checking for Sleep... yes checking whether mkdir accepts only one arg... yes checking for dot... NO checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.18... yes checking for FFTW3F... yes checking for machine dependent speedups... x86 checking for cppunit-config... no checking for Cppunit - version = 1.9.14... configure: error: GNU Radio requires cppunit. Stop The file cppunit-config exists in my C drive in this folder C:\msys\1.0\src\cppunit-1.12.0 but still it gives me this error. Do you have a cppunit.pc file in /usr/local/lib/pkgconfig? Were the configure, make, and make install steps for cppunit-1.12.0 successful? Your gnuradio config.log file may give you more information on what ./configure was looking for and what it did or did not find. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sensitivity of USRP to power glitches
Marcus Leech wrote: Something I've noticed over the years with the USRP is that it seems unusually sensitive to power glitches, even tiny ones. Maybe ground noise? For example, removing an RF connector while the USRP is powered up can sometimes cause it to go into Protocol Error -71 in and endless loop, and other things that might introduce small amounts of ground noise. This morning, my wife started the vacuum cleaner outside my office. The USRP had been running entirely fine for 24 hours, and then as soon as the vacuum cleaner started (causing a small AC glitch), the USRP crashed with Protocol Error -71. I used to have problems when turning on a desk lamp or the computer speakers. On Windows I was getting usb_reap_async errors. Is this an USRP thing, or is it that the USB is rather noise sensitive, and you normally don't see it because 99% of USB devices are powered from the PC, rather than independently, as the USRP is. My problem went away when I upgraded my computer. This make me suspect that it is a USB problem. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: manually dc offset useful
feldmaus feldmann_mar...@gmx.de wrote: I also noticed the dc offset, which is needed, changes from signal generator to signal generator. Could this be true ? How to avoid this ? With the LFRX, the DC offset will depend on the DC resistance of your signal source. You need 50 ohms (at DC) on the input to get (approximately) zero offset. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum value of samples
Sebastiaan Heunis wrote: Can anyone please suggest a setup that I can use to test the maximum value of samples? I know that we have 16bit signed values. Looking at the ADC interface on the USRP, we sign extend each 12-bit sample and add 3 zeros to the right. This should give us a maximum value of 16376 for samples? I tried using a BasicRX daughterboard. I have a function generator, inputting a 20MHz, 10dBm signal into the db. In my app I mix this down to 100kHz using the cordic. I also decimate by 16. The PGA gain is set to 20dB. The FPGA build is the standard 2rx/2tx with hbf. The maximum sample value that I get with this is 8635, so I'm using about half of the ADC's dynamic range. You also need to consider the inherent gain of the CORDIC algorithm (approx. 1.647/2 in the USRP) and the effect of filtering out the negative frequency components of your signal. Because of these, you can use the full dynamic range of the ADC and never see sample values close to 16376. In fact, at 10dBm input and 20dB PGA gain I expect your ADC is clipping. Have you looked at a plot of your recieved waveform? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSL function error on Cygwin
Yong J. Chang wrote: I'm trying to use GNU radio on Cygwin environment. It has taken couple of days to compile depedent stuffs. I'm on my almost final stage. I have following error messages when I compile 'gnuradio-core'. *** Warning: This system can not link to static lib archive /usr/local/lib/libgsl.la. *** I have the capability to make that library automatically link in when . . . I definitely installed gsl_1_12 library. Any helps are appreciated. :) It should be looking in /usr/lib (not /usr/local/lib) and it should be looking for libgsl.dll.a (not libgsl.la). You should have a gsl.pc file in /usr/lib/pkgconfig. If you also have a gsl.pc file (with old or incorrect information) in /usr/local/lib/pkgconfig, that could be the problem. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failure - caused by posix_memalign.cc- in trunk built under Cygwin
- Original Message - From: Prior-Jones, Michael R m...@bas.ac.uk To: Michael Dickens m...@alum.mit.edu Cc: discuss-gnuradio@gnu.org Sent: Tuesday, February 17, 2009 9:58 AM Subject: RE: [Discuss-gnuradio] Build failure - caused by posix_memalign.cc- in trunk built under Cygwin Can you figure out if /usr/include/cygwin/stdlib.h is #included from / usr/include/malloc.h or /usr/include/stdlib.h or some other /usr/ include/[foo].h file? I'd rather #include a reasonably standard header file if at all possible. - MLD /usr/include/stdlib.h references it: #ifdef __CYGWIN__ #include cygwin/stdlib.h #endif /usr/include/cygwin/stdlib.h references valloc(), but valloc() is declared in /usr/include/malloc.h. So malloc.h is what you want to include for Cygwin. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failure - caused by posix_memalign.cc- in trunk built under Cygwin
- Original Message - From: Michael Dickens m...@alum.mit.edu To: Don Ward don2387w...@sprynet.com Cc: Prior-Jones, Michael R m...@bas.ac.uk; discuss-gnuradio@gnu.org Sent: Tuesday, February 17, 2009 10:38 AM Subject: Re: [Discuss-gnuradio] Build failure - caused by posix_memalign.cc- in trunk built under Cygwin On Feb 17, 2009, at 10:22 AM, Don Ward wrote: /usr/include/cygwin/stdlib.h references valloc(), but valloc() is declared in /usr/include/malloc.h. So malloc.h is what you want to include for Cygwin. Isn't malloc.h what was added in the first place to posix_memalign.cc, which caused this issue? No. What caused the issue is that valloc is not defined in the standard place (stdlib.h) on Cygwin; malloc.h was added to fix the problem on Cygwin, but it caused problems on other platforms. I'm good with adding in malloc.h into configure.ac, then into posix_memalign.cc with proper #ifdef around it. That will work with OSX, and won't hurt Linux, and sounds like it'll allow Cygwin to work. Eric / Johnathan ... comments? These are small / easy changes. - MLD This sounds good to me as long as there is no hazard in including malloc.h on other (non-Cygwin) systems that have it but don't need it. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [Commit-gnuradio] r10410 -gnuradio/trunk/gnuradio-core/src/lib/missing
Michael Dickens wrote: On Feb 10, 2009, at 11:17 AM, Don Ward wrote: As far as I can tell, MinGW has no standard aligned-memory allocation functions. Can we use malloc16.c (in gnuradio-core/.../ general) or something like gcell/lib/runtime/gc_aligned_alloc.cc instead? malloc16.c requires the use of both the specific allocating (malloc16Align () and calloc16Align ()) and freeing (free16Align ()) routines to do what it does, but it would work (even though it might waste a bit of memory when allocating, in order to guarantee both alignment as well as a means for storing the actual allocated pointer value) ... This could be an option for certain issues. gc_aligned_alloc () uses posix_memalign (), so that's not an option. A better solution makes use of some built-in memory-alloc-with- alignment function and uses the standard free () to dealloc. That's what the posix_memalign () function is meant to, and currently does, provide. Agreed, but as far as I can tell, Windows does not have an aligned memory allocation function that works with free() so this solution is not available. The best way to do this would be to add on to the posix_memalign.cc file for the specific OS and how it does allocating. Use the AC_CHECK_HEADER macro to check for the correct headers, then AC_CHECK_FUNCS to make sure the functions exist and are callable. Then #ifdef around the appropriate functions after the end of HAVE_VALLOC in posix_memalign.cc for how this OS does it. How about a test to automatically disable components that require posix_memalign during configuration? Thanks, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [Commit-gnuradio] r10410 -gnuradio/trunk/gnuradio-core/src/lib/missing
Michael Dickens wrote: Fix missing header include (Don Ward) Modified: gnuradio/trunk/gnuradio-core/src/lib/missing/ posix_memalign.cc === #include posix_memalign.h +#include malloc.h This change breaks compile on OSX ... malloc.h is in /usr/include/ malloc/ on OSX, and is not needed on OSX or LINUX to be best of my knowledge for this code to compile ... only for the Windows environment. Here's my suggested patch ... does no harm on Linux, takes care of the issue on Windows, and allows OSX to compile: Oops, this is my mistake. I should have seen that valloc() is supposed to be in stdlib.h (but isn't there in Cygwin). Thanks for fixing this. I'm worried, though, that valloc isn't available at all on MinGW. Is there another way to accomplish what is needed? -- Don W. Index: configure.ac === --- configure.ac (revision 10414) +++ configure.ac (working copy) @@ -127,7 +127,7 @@ AC_CHECK_HEADERS(linux/ppdev.h dev/ppbus/ppi.h sys/mman.h sys/ select.h sys/types.h) AC_CHECK_HEADERS(sys/resource.h stdint.h sched.h signal.h sys/ syscall.h) AC_CHECK_HEADERS(netinet/in.h) -AC_CHECK_HEADERS(windows.h) +AC_CHECK_HEADERS(windows.h malloc.h) AC_CHECK_HEADERS(vec_types.h) dnl Checks for typedefs, structures, and compiler characteristics. Index: gnuradio-core/src/lib/missing/posix_memalign.cc === --- gnuradio-core/src/lib/missing/posix_memalign.cc (revision 10414) +++ gnuradio-core/src/lib/missing/posix_memalign.cc (working copy) @@ -25,7 +25,10 @@ #endif #include posix_memalign.h + +#ifdef HAVE_MALLOC_H #include malloc.h +#endif #ifndef HAVE_POSIX_MEMALIGN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.233 / Virus Database: 270.10.20/1943 - Release Date: 02/07/09 13:39:00 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [Commit-gnuradio] r10410 -gnuradio/trunk/gnuradio-core/src/lib/missing
- Original Message - From: Michael Dickens m...@alum.mit.edu To: Don Ward don2387w...@sprynet.com Cc: GNU Radio Discussion discuss-gnuradio@gnu.org Sent: Tuesday, February 10, 2009 10:32 AM Subject: Re: [Discuss-gnuradio] Re: [Commit-gnuradio] r10410 -gnuradio/trunk/gnuradio-core/src/lib/missing On Feb 10, 2009, at 10:11 AM, Don Ward wrote: Oops, this is my mistake. I should have seen that valloc() is supposed to be in stdlib.h (but isn't there in Cygwin). Thanks for fixing this. I'm worried, though, that valloc isn't available at all on MinGW. Is there another way to accomplish what is needed? The standard way of dealing with most #include's is to have AC check them in configure.ac to see if they exist (e.g., AC_CHECK_HEADERS(malloc.h malloc/malloc.h stdlib.h)) then #ifdef around the #include to make it safe (e.g.: #ifdef HAVE_STDLIB_H #include stdlib.h #endif ). With enough of these, one can usually find the correct header files and routines for a given OS. If more than a few of these are required to find a given header / routine, then the user's code will generally be cleaner if all of this is moved to a common local header file which is then #include'd (e.g., as done for the posix_memalign () function). Do you know what MinGW requires to get posix_memalign.cc to compile and be usable? - MLD As far as I can tell, MinGW has no standard aligned-memory allocation functions. Can we use malloc16.c (in gnuradio-core/.../general) or something like gcell/lib/runtime/gc_aligned_alloc.cc instead? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Make fail...config.h:467: error: 'usleep'was not declared in this scope
Dan J wrote:
Thanks for the input. The result of fgrep -i sleep config.h is:
fgrep -i sleep config.h
/* Define to 1 if you have the `nanosleep' function. */
/* #undef HAVE_NANOSLEEP */
/* Define to 1 if you have the `sleep' function. */
/* #undef HAVE_SLEEP */
/* Define to 1 if you have win32 Sleep */
#define HAVE_SSLEEP 1
/* Define to 1 if you have the `usleep' function. */
#define HAVE_USLEEP 1
This says that configure thinks you have a usleep() function somewhere.
This is different from my MinGW installation.
#ifndef HAVE_USLEEP
int usleep(unsigned long usec); /* SUSv2 */
#ifndef HAVE_NANOSLEEP
static inline int nanosleep(const struct timespec *req, struct timespec
*rem) { return usleep(req-tv_sec*100+req-tv_nsec/1000); }
#if defined(HAVE_SSLEEP) !defined(HAVE_SLEEP)
/* TODO: what about SleepEx? */
static inline unsigned int sleep (unsigned int nb_sec) {
Sleep(nb_sec*1000); return 0; }
1) I only installed MinGW yesterday and used MinGW-5.1.4.exe.
2) Using w32api3.11
Your installation is much newer than mine, but I think I am using the same
w32api.
You need to find out where configure is finding usleep. Looking at
config.log (search for usleep) may help. You can also go to
/mingw/include, /usr/include, /usr/local/include, etc. and try fgrep usleep
*.h, fgrep usleep */*.h, fgrep usleep */*/*.h, etc. to look for it.
Then figure out why configure found it but your gnuradio compile didn't.
-- Don W.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Make fail...config.h:467: error: 'usleep' was not declared in this scope
Dan J wrote: Finally was able to successfully configure gnuradio on Windows XP with MinGW/MSYS but fails during make. Does anyone have an idea of what's going on here? . . . $ make make all-recursive make[1]: Entering directory `/usr/src/gnuradio-3.1.3' Making all in config make[2]: Entering directory `/usr/src/gnuradio-3.1.3/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/config' Making all in omnithread make[2]: Entering directory `/usr/src/gnuradio-3.1.3/omnithread' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -DOMNITHREAD_NT=1 -DPthreadDraftVersion=10 -I/usr/src/gnuradio-3.1.3/omnithread -I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -MT omni_time.lo -MD -MP -MF .deps/omni_time.Tpo -c -o omni_time.lo omni_time.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -DOMNITHREAD_NT=1 - DPthreadDraftVersion=10 -I/usr/src/gnuradio-3.1.3/omnithread -I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -MT omni_time.lo -MD -MP -MF .deps/omni_time.Tpo -c omni_time.cc -DDLL_EXPORT -DPIC -o .libs/omni_time.o In file included from omni_time.cc:23: ../config.h: In function `int nanosleep(const timespec*, timespec*)': ../config.h:467: error: `usleep' was not declared in this scope ../config.h:467: warning: unused variable 'usleep' make[2]: *** [omni_time.lo] Error 1 make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/omnithread' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gnuradio-3.1.3' make: *** [all] Error 2 There appears to be some confusion about what sleep functions are available in your installation. If you do fgrep -i sleep config.h in your top-level directory, you should see that HAVE_SLEEP is defined but HAVE_USLEEP and HAVE_NANOSLEEP are not. You should also see a declaration int usleep(..., which should prevent the error shown above. It sounds like configure thinks that it has found usleep, but when you go to compile it isn't found. Did you install MinGW recently? Did you use the automated installer? Do you know what version of w32api you have? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python Headers
Umair Nasir wrote: This means configure cannot find Python.h, which is part of the Python development header file package. Normally that package is named something like 'python-dev'. -Johnathan There is no such package in the setup.exe file for cygwin setup!! Where to get it? Python.h should be in /usr/include/python2.5. The Setup Package Search link at http://cygwin.com tells you that it is included in the standard python-2.5 package. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP working but problem with cygwin
yufeng wang wrote: I also just started to install cygwin. My first problem occurs when I tried to install fftw-3.1.3 package, after './configure --enable...', it says 'no acceptable c compiler found in path', thus I can't continue with the next step. Anyone has similar problems? How did u solve this? In your Cygwin shell, try the command echo $PATH. Does the result include /usr/bin? If not, there is a problem with the way you are running Cygwin. Now try the command which gcc. Does it say /usr/bin/gcc? If not, gcc is not installed correctly. The command cygcheck -c will show you what Cygwin packages are installed. You should see entries for gcc-core and gcc-g++. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP working but problem with cygwin
yufeng wang wrote: Hi, Don, Many thanks for you reply! I've installed gcc, my problem now is that 'make: command not found', do you have any idea on how to solve this? Yes. You need to install all of the Cygwin packages listed in Installing Cygwin packages on http://www.gnuradio.org/trac/wiki/CygwinInstallMain. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP working but problem with cygwin
teka yemane wrote: Finally, my USRP and gnuradio are working fine. now, i am having bad time with installing cygwin as my clients need the application in windows. Has any body used cygwin for gnuradio before or is it better to use MingW? please any body who has got some experience on this, send me some advice. I have been using GNU Radio on both. Instructions for installation are given in the wiki (www.gnuradio.org/trac/wiki/WindowsInstall) . The instructions have been tested for release 3.1.3 but will not always work for the svn trunk (because the code changes faster than the wiki). There could also be problems with changes in Cygwin components or in the libraries that GNU Radio depends on. I think Cygwin is a little easier to start with, though MinGW doesn't change as fast. If you can be specific about the difficulties you are having, someone may be able to help. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] installation problem in gnuradio using cygwin
teka yemane wrote: hello there, I was installing gnuradio-3.1.3 in windows using cygwin. The ./configure worked fine but the make command results in the follwing error: ar: .libs/gr_hier_block2.o: No such file or directory make[5]: *** [libruntime.la] Error 1 make[5]: Leaving directory `/usr/src/gnuradio-3.1.3/gnuradio- core/src/lib/runtime' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/src/gnuradio-3.1.3/gnuradio-core/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/gnuradio-3.1.3/gnuradio-core/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/gnuradio-3.1.3/gnuradio-core' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gnuradio-3.1.3' make: *** [all] Error 2 can anyone give me some advice regarding this error and has any body successfully installed the gnuradio using cygwin? Yes, others have installed GNU Radio on Cygwin. Were you using the instructions at http://www.gnuradio.org/trac/wiki/CygwinInstallMain? Did you check the output listing to see what happened when gr_hier_block2.cc was compiled? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bootstrap error in gnu trunk
I am using the cygwin environment. As my college doesn't allow the svn command to download the latest gnuradio trunk, giving the error 'cannot resolve hostname', so I used the windows based software 'TortoiseSVN' and downloaded everything in the folder 'gnuradio'. Does the svn within cygwin perform the same function as what the software 'tortoisesvn' did for me? Yes, except that it doesn't add an extra character to every line. I read the svn+lineseparator issue on the page ---and applied the proposed fix but it gave the same error as posted below. Anyhow I copied this 'gnuradio' folder to c:\cygwin\usr\src, so using the bash i entered the command ./bootstrap I got the following error. ./bootstrap: line 2: $'\r': command not found ./bootstrap: line 21: $'\r': command not found ./bootstrap: line 22: $'\r': command not found ./bootstrap: line 24: $'\r': command not found ': No such file or directorydirectory `config ./bootstrap: line 26: $'autoconf\r': command not found ./bootstrap: line 27: $'autoheader\r': command not found 'ibtoolize: unrecognized option `--automake libtoolize: Try `libtoolize --help' for more information. 'utomake-1.10: unknown warning category `none configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). configure.ac:84: installing `./install-sh' ./bootstrap: line 31: $'\r': command not found ./bootstrap: line 33: syntax error near unexpected token `$'\r'' '/bootstrap: line 33: `(cd usrp2/firmware ; ./bootstrap) Can anybody figure out the error? Perhaps you should look at bootstrap and see if it looks like normal text. Compare it to something like configure.ac. My guess is that you will need to run dos2unix on bootstrap, and possibly on other files not mentioned in the WindowsTips wiki page. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error on Build of wxPython
Mark Petzold wrote: I'm trying to build and setup wxPython, and at step 9 of the wiki instructions (http://gnuradio.org/trac/wiki/wxPythonCygwin) I get a g++ error, as apparently a library isn't linking. Some background: I'm installing on Cygwin on Windows XP, and have followed the instructions to use binutils 20080523-1. $ python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 [...] build/temp.cygwin-1.5.25-i686-2.5/src/msw/_controls_wrap.o:_controls_wrap.cpp:(.text+0xcddf8): undefined reference to `__imp___ZTV23wxDatePickerCtrlGeneric' [etc.] Once again, it appears that a change in the wxPython release has broken the Cygwin build. I don't know how it is supposed to work, but I made it work by doing the following: After running ../configure, find the file build-local/lib/wx/include/msw-ansi-release-2.8/wx/setup.h and after the line: #define wxUSE_DATEPICKCTRL 1 add another line: #define wxUSE_DATEPICKCTRL_GENERIC 1 then continue with the directions in the wiki. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: libtool 2.2
Johnathan Corgan wrote: The 3.1.3 release tarballs were bootstrapped with libtool 2.2. Please let me know if this fixes your issue on Cygwin. I am pleased to report that release 3.1.3 installs on Cygwin with no patches and no need to run bootstrap (see http://www.gnuradio.org/trac/wiki/CygwinInstallMain). The only remaining issue is that libtool 2.2 sometimes uses installed libraries instead of libraries from the build tree when running make check, so you must uninstall any previously installed version of GNU Radio before running make check. Is there a way to remove obsolete attachments from a wiki page or edit their descriptions? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error - gnu radio installation
Narayanan,Sivaramasubramanian (RT) wrote: I get the following error while executing make. make[4]: Entering directory `/cygdrive/c/gnuradio-3.1.2/usrp/doc' mkdir -p html xmlto html-nochunks ../../usrp/doc/usrp_guide.xml xmlto: input does not validate (status 3) error : Operation in progress /cygdrive/c/gnuradio-3.1.2/usrp/doc/../../usrp/doc/usrp_guide.xml:4: warning: failed to load external entity /cygdrive/c/gnuradio-3.1.2/usrp/doc/docbookx.dtd A search for cygwin xmlto in the gnuradio mail archives turns up http://lists.gnu.org/archive/html/discuss-gnuradio/2008-05/msg00163.html. In summary, xmlto does not seem to work with GNU Radio on Cygwin. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Make Check Failures under FC9 on Intel
Eric Blossom wrote: On Wed, Jun 18, 2008 at 01:53:33PM -0400, Suprin, Charles E. wrote: Eric, Looks like the current compiler in g++ --version g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) Copyright (C) 2008 Free Software Foundation, Inc. I saw the earlier traffic that discussed a compile problem from around June 2 2008. However now we pass compile and fail the checks. Charles I supect a compiler bug. Here's the list of bugs fixed from 4.3.0 to 4.3.1 http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDresolution=FIXEDtarget_milestone=4.3.1 I suggest testing with gcc 4.3.1 and see if the problem is still there. If it's gone, problem solved, otherwise there's more sleuthing to do. I ran into this today with gcc 4.3.1 on Debian (testing). Line 101 of qa_gr_fxpt_nco.cc new_nco.sincos ((gr_complex*)new_block, SIN_COS_BLOCK_SIZE); only fills the first 1696 members of new_block (though SIN_COS_BLOCK_SIZE = 10). Adding printf statements to new_nco.sincos or compiling qa_gr_fxpt_nco.cc with -O1 makes the problem go away. -- Don W. -Original Message- From: Eric Blossom [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2008 1:43 PM To: Suprin, Charles E. Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Make Check Failures under FC9 on Intel On Wed, Jun 18, 2008 at 11:18:47AM -0400, Suprin, Charles E. wrote: Hello, I am attempting to install and compile the svn version 8598 version of gnuradio on a Fedora 9 Pentium 4. It compiles fine but throws errors during make check. !!!FAILURES!!! Test Results: Run: 90 Failures: 1 Errors: 0 1) test: qa_gr_fxpt_nco::t1 (F) line: 101 qa_gr_fxpt_nco.cc double equality assertion failed - Expected: -0.857728600502014 - Actual : 0 - Delta : 9.9974737875e-06 It seems there is an issue both in how it computes the actual and the Delta. A few quick Google searches and scanning the mailing list did not show any one else having the issue. Is anyone else having this issue? Charles I believe I saw this or something like it when I tested with gcc 4.3.0 a few months ago. I didn't worry too much about it since the list of known bugs for the compiler was pretty long, and this was the first release of 4.3.0 What version of g++ is shipping with F9? $ g++ --version Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.0/1507 - Release Date: 6/18/2008 7:09 AM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installation problem with cygwin
Nan Zhang [EMAIL PROTECTED] wrote: I tried to install numpy under cygwin using the method given in http://gnuradio.org/trac/wiki/NumpyInstall as follows cd /usr/src tar zxf numpy-1.0.3.1.tar.gz cd numpy-1.0.3.1 python setup.py install but always failed. Could someone help? You need to be much more specific about what went wrong. Beside that, I have a python and numpy installed under windows. Were you running the Windows python or Cygwin python? To use GNU Radio under Cygwin you need to use the Cygwin python. I am wondering if there is some way to take use of the windows version for gnuradio? Yes, this can be done using MinGW (see instructions in the wiki). -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: SVN Compile Error Under Cygwin: Omnithread Stuff
Hi Sivaram, Narayanan, Sivaramasubramanian (RT) wrote: I'm trying to Install GNU Radio using Cygwin in my Windows system. When I do make, I get the following error: /cygdrive/c/gnuradio-3.1.2/gnuradio-core/src/lib/swig/gnuradio_swig_py_r untime.c c:(.text+0x34fa4): undefined reference to `omni_thread::init_t::init_t()' [...] I referred the patches given in the following pages: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg09570.html I applied the patch given in the site http://www.gnuradio.org/trac/ticket/138, but my error still exists. I also tried the makefile.patch by Don Ward given in the URL: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg10039.html I still run with the same problem. Kindly suggest me ways to get out of this. The latest patch and instructions on how to use it are given in the wiki at http://www.gnuradio.org/trac/wiki/CygwinInstallMain. Be sure to do the ./bootstrap after applying the patch. With any luck, this should be the last release to have this problem. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: mblock make failure under Cygwin
Eric Blossom wrote: .libs/qa_inband_usrp_server.o: In function `_ZN5boost6detail17sp_counted_impl_pI12qa_alloc_topE11get_deleterERKSt9type_info': /usr/include/boost-1_33_1/boost/detail/sp_counted_impl.hpp:(.text+0x9b): undefined reference to `mb_mblock::~mb_mblock()' It looks like you are missing a patch (attachment:makefiles6975.patch, listed on the Cywin wiki page) needed to include the mblock library in the link of qa_inband_usrp_server. -- Don W. Thanks Don. FYI, we haven't applied this patch to the trunk because the real problem is with libtool under cygwin. The patch replicates information (always a bad idea) that libtool already knows on all other systems. Good news: libtool 2.2.2 is now available on Cygwin and seems to handle the interlibrary dependencies. Bad news: (a) using the new libtool requires running bootstrap (to get new ltmain.sh, libtool.m4, ...?), so it still requires a patch (to add bootstrap) to work with the current release; and (b) autoconf (and/or libtoolize?) produce a number of warnings, such as LT_OUTPUT was called before LT_LANG. (I think there are some compatibility issues, but I haven't found any simple documentation on them yet.) Unknowns: I don't know if libtool 2.x runs on MinGW, and I haven't tried it on Debian (to see if it gets the same warning messages). -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with Installation of GNU radio
Hi Prasanna, I tried installing GNU radio in windows using cygwin. I did it as it was given on the gnuradio.org website. I initially built a minimal GNU radio system, with just omnithread, gnuradio-core and gr-audio-oss modules enabled and it worked fine. Then I when I tried to build a full GNU radio system, it gave me the following error in the usrp module- mkdir -p html xmlto html-nochunks ../../usrp/doc/usrp_guide.xml xmlto: input does not validate status 1 http://www.oasis-open.org/docbook/xml/4.2/1:parser error : Content error in the external subset ! DOCTYPE html I have not been able to make xmlto work with the GNU Radio xml files on Cygwin. Since this is just the documentation that is failing, you can build GNU Radio without it. One way is to get rid of xmlto (uninstall it with Cygwin setup, remove it from /usr/bin, or rename it), then rerun configure and try it again. Another solution is to edit usrp/doc/Makefile to remove usrp_guide.html from the DOCBOOK_HTML_FILES line, but you will need to do this every time you run configure. The best solution (aside from making xmlto work) would be to figure out how to tell configure to ignore xmlto. If anyone knows why xmlto doesn't work (on Cygwin), please let us know. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to Build and Install wxPython for Microsoft Windows under Cygwin ?
Hi Linh, I followed your instructions on http://www.gnuradio.org/trac/wiki/wxPythonCygwin but I failed when I got to step (9): python setup.py build_ext --inplace WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 The error message I got was undefined reference: build/temp.cygwin-1.5.25-i686-2.5/src/msw/_misc_wrap.o:_misc_wrap.cpp:(.text+0x2df03): undefined reference to `__imp___ZN11wxLogStderrC1EP9__sFILE64' This should be defined in /usr/local/lib/libwx_base-2.8.dll.a. You can verify that it is defined there with strings /usr/local/lib/libwx_base-2.8.dll.a | fgrep ZN11wxLogStderrC1EP9 If it is not there, then you have a problem with an earlier step in the installation. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ais-tools installation problem
irene159 wrote: Well I downloaded mysql-3.23.43, I am not sure I’ve done the right choice. I did do some Internet research before installing it and that’s when I realized that there are many problems with mysql running on Cygwin although this version was said to work. Can somebody confirm? The point is there is no libmysqlclient.dll. I run ./configure, make and make install with no problem Try ./configure --help (in your mysql directory) and see if you have options like --enable-static, --enable-shared, --disable-static, and/or --disable-shared. Depending on the defaults, to build a shared library (a *.dll file on Windows---what you need) you may need to specify --enable-shared --disable-static on your ./configure. Look carefully in the output of ./configure and you should be able to find where it says if it is building shared or static libraries. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ais-tools installation problem
irene159 wrote: I just noticed that I missed some things on the make output [3], specially: *** Warning: linker path does not have real file for library -lmysqlclient. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libmysqlclient and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/python2.5/config/libpython2. 5.dll.a *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module _ais. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. So there is still a problem with libmysqlclient. I have libmysqlclient.a and libmysqlclient.la in /usr/local/lib/mysql. What does linker path does not have real file for library -lmysqlclient mean? It is looking for libmysqlclient.dll but couldn't find it, so it built a static library (which is useless) instead. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Cygwin install problem
Don - Thanks for the info. I tried this but initially had a problem with the first export statement due to the space before the equal sign. Apparently that's not allowed. After that, configure went ok but I got the following problem during make: g++: I/usr/local/include/SDL: No such file or directory In file included from video_sdl.cc:3585: video_sdl_sink_uc.h:28:17: SDL.h: No such file or directory [...] Sorry about that. The first line got garbled. Instead of export SDL_CFLAGS =I/usr/local/include/SDL it should read: export SDL_CFLAGS=-I/usr/local/include/SDL (no space, but with -). -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MinGW install problem
Rob Walker wrote: I have a working version of GNU Radio 3.0.4 on a MinGW system and noticed that new instructions had been posted for 3.1.2 so thought I'd give it a shot but ran into the following problem when running the ./bootstrap command just after the makefiles patch: $ ./bootstrap configure.ac:21 http://configure.ac:21/ : error: Autoconf version 2.57 or higher is required [...] I'm pretty sure I followed all the instructions up to that point and used all the correct file versions, but when I did an autoscan -V I saw that I have version 2.56 of autoconf.Can anyone help? GNU Radio 3.1.2 requires several MSYS/MinGW packages that were not required by earlier releases. You need the following: - autoconf 2.59 (or later) - automake 1.9.5 (or later) - libtool 1.5 (or later) These are available from the sourceforge MinGW/MSYS repository as autoconf-2.59-mingwPORT.tar.bz2, automake-1.9.5-mingwPORT.tar.bz2, and libtool-1.5.22-mingwPORT.tar.bz2. To install these, download the files to /usr/src, unpack them with tar jxf, cd to the each unpacked directory, and build the package with ./mingwPORT.sh. If you get wget: command not found, you will first need to download wget-1.9.1-mingwPORT.tar.gz, unpack it with tar zxf, and copy mingwPORT/wget.exe to /usr/local/bin. I also needed an extra step to work around a problem in automake: aclocal_exe=`which aclocal` sed s,C:/,/C/,g $aclocal_exe aclocal.tmp mv -f aclocal.tmp $aclocal_exe You may need to repeat the above step, substituting autoconf for aclocal. You may need to start a new MSYS shell for the new versions of the above tools to be seen. These added requirements are also required for building from the svn repository. They are needed because the Windows versions of libtool do not know how to track interlibrary dependencies. Let me know if these instructions work or if they need corrections. When we get a set that works, I will add them to the wiki. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cygwin install problem
Rob Walker wrote: I have a working version of GNU Radio 3.0.3 on a Cygwin system and just tried to install 3.1.2. I followed the instructions on the wiki page and configure went ok but I got the following error message during the make: In file included from /usr/include/python2.5/Python.h:57, from video_sdl.cc:129: /usr/include/python2.5/pyport.h:230:24: sys/select.h: No such file or directory When building under Cygwin, the SDL package specifies flags to build native Windows code (using MinGW include files) without the Cygwin compatibility library. This should work except that the flags used (-mno-cygwin, in particular) are stored in sdl.pc (the pkg-config configuration file) and picked up by GNU Radio. When these flags are used to build the Python extension module, they prevent Cygwin-specific include files (e.g., sys/select.h) used by Python.h from being found. In essence, ./configure is determining what libraries are available on one system (Cygwin) while the flags read by pkg-config for SDL are specifying flags for a different system (native Windows, using MinGW include files). (Note that the actual conflict here comes from pyconfig.h, which should agree with ./configure as to what include files are available.) A possible workaround for this case is to override the SDL flags in the pkg-config file: cd gnuradio-3.1.2 export SDL_CFLAGS =I/usr/local/include/SDL export SDL_LIBS=-lSDL ./configure ... This compiles and links without errors, but I haven't been able to test whether gr-video-sdl works or if SDL's opting to bypass the Cygwin library causes problems for this application. Is there a better solution? Should SDL be putting flags like -mno-cygwin in sdl.pc? -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using rb vs. r to open gnuradio data files
Rob Walker wrote: I was attempting to use Chuck Swiger's utility at http://www.swigerco.com/gnuradio/raw2num_f.c to read a gnuradio file created by audio_to_file.py but kept getting Input reached EOF well before the entire file had been read. I am not a C programmer, but while debugging I noticed that he had used r in his fopen command rather than the rb used by gr_file_source.cc so I made that change and now the utility works fine. I also noticed an old post from ematlis (http://lists.gnu.org/archive/html/discuss-gnuradio/2007-05/msg00341.htm l) mentioning a similar utility he'd developed and noticed it uses r rather than rb also. Shouldn't rb be used rather than r to open gnuradio data files? By the way, I am using MinGW/MSYS with GCC 3.4.5 if that matters. Windows (MinGW/MSYS and Cygwin) needs to know when to convert the CR-LF line separators stored in a text file to LF on reading (text files) and when to leave them alone (binary data). For portability, I think that all files that are not text files should be opened with rb. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS on USRP
Phaysal Khan wrote: I used usrp_fft, and I can see a CW at 1575.42MHz, so it means that it is in the working condition, although I still get the same error msg once everytime i run anything. It says $python usrp_fft.py -f 1.57542G usb_contro_msg failed: usb_control_msg: sending control message failed, win error: A device attached to the system is not functioning. Under Windows (both Cygwin and MinGW) I get this message every time I start a GNU Radio application that uses the USRP. I haven't been able to figure out why, but it doesn't seem to affect the operation of the USRP or GNU Radio. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Waterfallsink
Hi Rob, I see strange waterfall behavior in a MinGW installation on a Windows machine. The problem is that the waterfall does not automatically update. If I minimize the window then maximize it, it will be updated. If I drag another window over the top of it, only the portion that the window was dragged over will be updated. If I right click over the window so that the pop-up menu appears, when the menu goes away the area under it has been updated. I've had the same problem on two different machines. Anyone know an easy fix for this problem? I remember this problem, but I'm not sure I remember the solution. Try adding the line: del dc1 before the line self.DoDrawing (None) at the end of set_data(). I think the problem was that self.bm was still selected into dc1 and that prevented it from being used properly in dc. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ./configure on Cygwin fails at SDL because of noalloca.h
Casey Tucker wrote: I'm trying to make GNUradio work properly on cygwin now. I've configured and compiled SDL 1.2.13 normally, and my sdl-config has -mno-cygwin in its --cflags. GNUradio still fails to find SDL properly when configuring, stating that it cannot find alloca.h. I've done a lot of googling on the subject, and cannot seem to deduce how to make SDL and gnuradio work together on cygwin. So my question is this: has anyone had success in this regard, and if so, how exactly did that come about? Maybe I need a lower version of SDL, or need to configure SDL differently? I don't know of anyone who has tried to make SDL work with GNU Radio on Cygwin. Might there be a problem if SDL is configured with -mno-cygwin and GNU Radio is not? They may not agree on which include files and library functions (e.g., alloca.h and alloca) are available. You may need to modify the configure file for SDL to fix this. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and gnuradio errors - seems todisconnect often
Casey Tucker wrote: I would like to get the SVN (or at least a more recent) version to compile under Windows, but the Wiki articles do not indicate which libraries are compatible, and I think this is a real shame for those of us who prefer to enable non-linux-gurus to use FOSS. Any advise on compiling under MSYS or Cygwin would be greatly appreciated. Except as noted, the libraries needed for the SVN build under Cygwin are the same as for the release. If you run into trouble, post specifics to the list and we can find a solution and update the wiki. The MinGW wiki is more likely to be out of date. (I assume you are looking at http://www.gnuradio.org/trac/wiki/CygwinInstallMain and not some older wiki page.) -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
