Hints, Tips, Known
Problems, and Solutions for Windows
The following topics may be useful to users of GNU Radio on Windows.
Note
that some of the Cygwin topics may also apply to MinGW/MSYS and vice versa.
Building GNU Radio on Windows
Instructions for installing GNU Radio on Windows are given elsewhere. This
page describes potential difficulties.
Line Separators in Text Files;
Subversion; !^M
UNIX and Linux use the newline character (sometimes written as
LF; sometimes displayed as ^J; '\n' in C) to separate
lines in a text file, while Windows uses a two-character sequence of
carriage-return followed by newline (CRLF or ^M^J; "\r\n" in C).
Cygwin and MSYS tend to follow the UNIX/Linux convention, so if your text files
use the Windows convention you may see extra ^M characters in
unexpected places (like in error messages!). One way to tell if a file has
Windows or UNIX line endings is to open it with Windows Notepad: If the file
looks normal it uses CRLF, but if the lines are run together with little boxes
between them it uses LF only.
Subversion (the svn program) is designed to convert files (if
requested by the developer) to use the "native" line separators of the target
machine when checking out code. That means that a Windows version of
svn will use CRLF separators and a UNIX/Linux version of
svn will use LF. Thus if you go to http://subversion.tigris.org and
download and install Windows binary version of svn (or use
TortoiseSVN), you will get CRLF line separators. If you install the Cygwin
subversion package (using Cygwin setup), you will get LF
separators. Known problems with CRLF separators. All known
problems with line separators have been fixed in the svn
repository. If any new problems are introduced, they might look like:
config.status: creating \^M
config.status: error: cannot find input file: \^M.in
This is because some of the ^M characters in some of the
.m4 files in the config directory are being treated as
ordinary characters instead of as line separators. This can be fixed with:
$ cd gnuradio
$ dos2unix config/*.m4 configure.ac
(The dos2unix program can be found in the Cygwin
cygutils package or in the mingw-utils package.)
tar.gz or tar.tar ?
Sometimes when you download a package (such as FFTW) labelled
"thing.tar.gz" it will be put on your system with the filename
"thing.tar.tar". This does not cause any problems except that you
must change any commands that refer to the downloaded file to use the actual
filename on your system.
Permissions problem
installing packages on CygwinIf you get
errors like
/usr/bin/install -c -d /usr/local/bin
/usr/bin/install: cannot change permissions of @/usr/local/bin': Permission denied
when installing a package (such as wxPython), you will need to change
the owner of the /usr/local/bin and /usr/local/lib
directories. To do this, first find your username with the whoami
command. Then find the current owner of the directories in question with
ls -ld /usr/local/{lib,bin}
Log in to the account of the current owner and use the command
chown username /usr/local/{lib,bin}
to change the owner to the username you wish to use for the
installation. Or you can just do the installation from the account that owns
/usr/local/bin and /usr/local/lib.
Please note for Windows Vista, make sure the User Account Control is turned
OFF. That blocks the permission to the folders, even though you have the
ownership.
libtool 2.2: Good
News and a Warning (Cygwin and MinGW)
With libtool 2.2 we no longer need to patch Makefiles before building on
Cygwin or MinGW. When building from an older
tarball (3.1.2 or earlier) you will get a bunch of warnings running ./bootstrap,
but it should work; building from the svn trunk should give only a few
warnings.
But there is a problem with libtool 2.2: When running make check
it tends to find installed libraries instead of the ones you want to test. Thus
you either need to make uninstall any old version you may have or
make install the new version before running make
check. On Cygwin, libtool 2.2 is available as a current package. On MinGW download http://ftp.gnu.org/gnu/libtool/libtool-2.2.4.tar.gz;
unpack it and install it in /mingw it with:
$ tar -zxf libtool-2.2.4.tar.gz
$ cd libtool-2.2.4
$ ./configure --prefix=/mingw
$ make
$ make install
Note: It may be easier to install
libtool-2.2.7a-1-mingw-bin.tar.lzma from the MinGW Sourceforge page.
Boost Library on Cygwin and MinGWStarting
with release 3.1.3, GNU Radio requires boost 1.35 or later. To install boost
1.40.0 on Cygwin, download boost_1_40_0.tar.bz2 from http://sourceforge.net/projects/boost/files/boost/1.40.0/
to /usr/src and install it with:
$ cd /usr/src
$ tar -jxf boost_1_40_0.tar.bz2
$ cd boost_1_40_0
$ ./bootstrap.sh --with-libraries=thread,date_time,program_options
$ ./bjam install
This installs the boost include files in
/usr/local/include/boost, the import libraries in
/usr/local/lib, and the .dll files in /usr/local/bin.
The libraries and DLLs have funny names, but GNU Radio will find them. On MinGW, download
and untar boost as above, then install with:
$ ./bootstrap.sh --with-toolset=mingw
$ ./bootstrap.sh --with-libraries=thread,date_time,program_options --with-bjam=tools/jam/src/bin.ntx86/bjam
$ ./bjam --prefix=/usr/local link=shared install
$ mv /usr/local/lib/*boost*.dll /usr/local/bin
The first ./boostrap.sh creates the bjam
program for MinGW, but then can't find it. On the
second ./bootstrap.sh we tell it where the find bjam
so it can complete the build. The extra arguments to ./bjam are
needed to get shared libraries and include files in the proper places.
Installing the boost libraries is one of the most time-consuming steps in
installing GNU Radio. Time for a nice, long walk? The boost thread library is
used by the svn trunk version of GNU Radio to provide thread-per-block (TPB)
scheduling. For this to work on MinGW, you must specify the environment
variable
$ export CXX="g++ -mthreads"
before running ./configure. You can go back to the
original single-threaded scheduler (on either Cygwin of MinGW) by setting the environment
variable
$ export GR_SCHEDULER=STS
before running GNU Radio.
Warnings About .stabn and
.stabsWhen compiling gnuradio_swig_python.cc you may get a lot(!) of warnings like:
/cygdrive/c/DOCUME~1/Don/LOCALS~1/Temp/ccr02wlm.s:2443775: Warning: .stabn: description field '20a34' too big, try a different debug format
/cygdrive/c/DOCUME~1/Don/LOCALS~1/Temp/ccr02wlm.s:2443818: Warning: .stabs: description field '1ebc9' too big, try a different debug format
These are annoying because of the large number of them, but don't appear to affect the working of GNU Radio. <pre>
<pre>
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
^
</pre>
<pre>
h3. Broken Packages in Cygwin
Some versions of some packages don't work with GNU Radio:
* boost; boost is ok, but you don't need it; what you need is boost-devel
* cppunit 1.9.14-1; use version 1.12.0 instead
* fftw3 3.0.1-2; does not include single precision; build your own instead
* binutils 20060709-1 (obsolete); causes "Permission denied" errors on wxPython
* binutils 20080523-1; causes build errors in wxPython and Numpy
* gcc-core and gcc-g++ older than 3.4.4-2; require patches in GNU Radio and CppUnit to work around a problem with strings passed between DLLs
* xmlto; causes build to fail while attempting to produce documentation
Some Cygwin setup mirror sites may contain out-of-date versions of some Cygwin packages. If @demo.py@ did nothing when you installed wxPython or if @dial_tone.py@ does nothing (exits immediately or produces a Windows error pop-up), you may have obsolete packages. Check to see that the mirror you are using in Cygwin setup is on the current list. In any case, you may want to try a different mirror to see if it has more up-to-date packages. You may
need to @make uninstall@ and delete your GNU Radio directory and start over with a new tarball or svn checkout.
h3. Broken Packages in MinGW/MSYS
* binutils 2.16.91-20060119-1; causes Windows error popup when linking @libgnuradio-core.la-3.0@; use 2.17.50-20060824 instead
* MSYS-1.0.11-2004.04.30-1.exe; treats the files @foo@ and @foo.exe@ as the same file, even when @libtool@ wants them to be different; the result is that @make check@ in GNU Radio hangs when running @test_*@; to fix, install MSYS-1.0.11-20060807.tar.bz2; 1.0.10 doesn't have this problem
* bash 2.04 (the default that comes with MSYS); considers an empty @for@ loop (e.g., "@for i in ;@") to be a syntax error; fix by installing bash-3.1-MSYS-1.0.11-snapshot.tar.bz2
* bash 2.05b; doesn't understand "C:/" paths on some commands (e.g., @cd@ or @exec@); use bash 3.1 instead
* automake 1.7.1 (the default that comes with MSYS); produces a @libtool@ script that can't find necessary library files (e.g., @-lwinmm@) causing static archives (useless for GNU Radio) to be built instead of DLLs; fix by installing automake-1.9.5-mingwPORT.tar.bz2; this is only needed if building from svn; (msys-automake-1.8.2.tar.bz2 may work, but hasn't been tested)
* autoconf 2.56 (the default that comes with MSYS); not new enough for building from svn; autoconf-2.59-mingwPORT.tar.bz2 works, but you need to edit aclocal to change "C:/" to "/C/"; (msys-autoconf-2.59.tar.bz2 may work but hasn't been tested)
Some of the MinGW/MSYS packages you want may be missing from http://www.mingw.org/download.shtml, but they are all on http://sourceforge.net/project/showfiles.php?group_id=2435 (note that you may need to click on the "View older releases" link to find them, even when looking in the "Current" or "Snapshot" sections).
Some MinGW packages are available as mingwPORT packages. These are scripts that download, patch (if necessary), and install components. To use these you must first download wget-1.9.1-mingwPORT.tar.bz2, unpack it, find @wget.exe@ and copy it to @/mingw/bin@ or @/usr/local/bin@. Then you can install a mingwPORT package by downloading the file to @/usr/src@, unpacking it, going to the directory with the @mingwPORT.sh@ file and running @./mingwPORT.sh@ and answering the questions (default answers work if you downloaded to @/usr/src@).
h2. Audio Devices on Windows
The available audio device on Windows are:
* windows audio (audio_windows aka gr-audio-windows)
* OSS audio (audio_oss aka gr-audio-oss) (Cygwin only)
* portaudio (audio_portaudio aka gr-audio-portaudio) (requires library)
h3. Available Audio Devices
*Windows Audio.* The obvious audio device to use on Windows is audio_windows (gr-audio-windows in the source, audio_windows in Python). Unfortunately, audio_windows is only partially implemented: audio_windows.source doesn't work at all, and audio_windows.sink doesn't recognize the @ok_to_block@ parameter so programs like multi_tone.py (in gnuradio-examples/python/audio) fail with the message:
<pre>
File "/usr/local/lib/python2.4/site-packages/gnuradio/audio_windows.py", line 201, in sink
return _audio_windows.sink(*args)
NotImplementedError: No matching function for overloaded 'sink'
</pre>
It is possible that audio_windows will be fixed in a future release. In the meanwhile you can use it for output only, and you may need to modify programs that use the @ok_to_block parameter@ when creating an audio sink.
*OSS Audio.* OSS (Open Sound System) audio (gr-audio-oss or audio_oss in Python) is designed for UNIX systems but is available on Windows under Cygwin. The Cygwin implementation can capture and play sounds (i.e., audio source and sink both work) but not at the same time. OSS audio is not available under MinGW.
*!PortAudio.* PortAudio (gr-audio-portaudio or audio_portaudio) is a portable audio library that lets programmers access a variety of audio devices and libraries using a single programming interface. On Windows, it can be used to do audio capture and play using the traditional Windows interface, DirectX, kernel streaming, ASIO, or WASAPI (new in Windows Vista) interfaces. It can capture and play sounds (i.e., use the source and the sink) at the same time.
To use PortAudio, you must download and build the v19-devel version of the
PortAudio library. This is easy on Cygwin and MSYS (see PortAudioInstall).
h3. Selecting an Audio Device
There several ways to select which audio device to use:
* only include one device in your GNU Radio build
* use the default device chosen by @audio.py@
* specify a device in @~/.gnuradio/config.conf@
* specify a device in your Python program
*Include only one device in your build.* If you are satisfied with one of the availble audio devices, you can exclude all others from your build of GNU Radio by using options like @--disable-gr-audio-xxx@ on @./configure@. For example, if you have PortAudio and don't wish to use Windows audio or OSS audio, you can say:
<pre>
$ ./configure ... --disable-gr-audio-oss --disable-gr-audio-windows ...
</pre>
With only PortAudio available, it will be used. This does not work to select Windows audio, however. Even if gr-audio-windows is the only audio module included in the build, it will not be used unless specifically requested.
*Use the default device chosen by @audio.py@.* When you tell Python
<pre>
from gnuradio import audio
</pre>
@audio.py@ returns the first module that loads successfully from the following list:
* @audio_alsa@
* @audio_oss@
* @audio_osx@
* @audio_jack@
* @audio_portaudio@
For Windows users, this means that @audio_oss@ is the first choice and @audio_portaudio@ is the second choice. Note that @audio_windows@ is not on the list and will not be chosen.
*Specify a device in @~/.gnuradio/config.conf@.* The file @.gnuradio/config.conf@ in your home directory can be used to specify defaults for GNU Radio. For example, to tell
<pre>
from gnuradio import audio
</pre>
to import @audio_windows@, include the following lines
<pre>
[audio]
audio_module: audio_windows
</pre>
in @config.conf@.
*Specify a device in your Python program.* If a particular Python program needs a particular audio device, you can request that device on the @import@ statement:
<pre>
from gnuradio import audio_portaudio as audio
</pre>
By including @as audio@, you can reference the imported module as @audio@ (e.g., @audio.sink@); if you later want to use a different audio module, you only need to change the @import@ statement.
h2. USRP on Windows
Windows is supposed to detect when a USB device (such as the USRP) is added or removed, so the USRP should work when it is powered up and attached to the computer. In practice you may get errors of two sorts when trying to access the USRP. The most common error is:
<pre>
usrp: failed to find usrpr0
[Python traceback appears here]
RuntimeError: can't open usrp1
</pre>
This error appears the first time you attempt to access the USRP after it is powered up, and is accompanied by the Windows sounds that indicate disconnection and reconnection of a USB device. It seems to occur when the USRP is known to be present but has not had its firmware downloaded. Once this error appears, it should not appear again until the next time the USRP is unplugged or reset.
The other error that can occur is:
<pre>
[first part of Python traceback]
File "/usr/local/lib/python2.4/site-packages/gnuradio/usrp.py", line 245, in +init+
_ensure_rev2(which)
File "/usr/local/lib/python2.4/site-packages/gnuradio/usrp.py", line 82, in _ensure_rev2
v = _look_for_usrp(which)
File "/usr/local/lib/python2.4/site-packages/gnuradio/usrp.py", line 76, in _look_for_usrp
raise RuntimeError, "Unable to find USRP #%d" % (which,)
RuntimeError: Unable to find USRP #0
</pre>
This error occurs when the USRP has been reset without Windows knowing about it. This can happen if you remove power from the USRP and reapply it while Windows is asleep (e.g., in hibernation mode). This error is not fixed by repeating the command that produced it. It is fixed by disconnecting and reconnecting either the USB or power to the USRP. The next time you try to access the USRP expect to get the @can't open usrp1@ error; after that it should work.
cppunit-1.10.2-win32.patch - patch for building cppunit 1.10.2 on Cygwin or MinGW/MSYS (861 Bytes) Redmine Admin, 10/06/2006 01:29 AM
user-config.jam - boost config file to produce better file suffixes (394 Bytes) Redmine Admin, 09/02/2008 08:34 PM
|
|
