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 Cygwin

If 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.

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 the 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.2 is available by checking the "Exp" button when using Cygwin setup; be carefull to not reinstall the old version when installing updates.

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

SWIG 1.3.31 on Cygwin

Building from the latest SVN trunk requires version 1.3.31 or later of SWIG, but (as of March 2008) the latest version available as a Cygwin package is 1.3.29. SWIG 1.3.31 can easily be built from source:

1. Use Cygwin setup to uninstall any existing version of SWIG
2. Download SWIG 1.3.31 from http://www.swig.org/download.html
3. Build and install with:

   tar zxf swig-1.3.31.tar.gz
   cd swig-1.3.31
   ./configure
   make
   make install
   

The only language SWIG needs to know about is Python, so you can save some time by using:

./configure --without-tcl --without-perl5 --without-java --without-gcj --without-guile \
--without-mzscheme --without-ruby --without-php4 --without-ocaml --without-pike \
--without-chicken --without-csharp --without-lua --without-allegrocl --without-clisp \
--without-r

The procedure above has also been tested for SWIG 1.3.34.

boost 1.36 on Cygwin and MinGW

Release 3.1.3 and the current svn trunk require boost 1.35 or later. To install boost 1.36.0, download it from http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&release_id=619445 to /usr/src and unpack it.

On Cygwin you may need to edit the file tools/jam/src/expand.c to change the line assert( !strcmp( l->string, "c:\\foo\\bar" ) ); to assert( !strcmp( l->string, "C:\\foo\\bar" ) ); (c: -> C:). If the ./configure doesn't work, change it back; it may depend on which version of Cygwin you are using. The rest of the installation is easy:

$ ./configure --with-libraries=thread,date_time
$ make
$ make install
$ cp /usr/local/lib/*boost*.dll /usr/local/bin

This installs the boost include files in /usr/local/include/boost-1_36, 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, install boost with:

$ ./configure --with-libraries=thread,date_time --with-toolset=mingw
$ ./configure --with-libraries=thread,date_time --with-bjam=tools/jam/src/bin.ntx86/bjam

Then download the attached user-config.jam to your boost source directory (replacing the one that was created by the ./configure command). Continue with:

$ make
$ make install
$ cp /usr/local/lib/*boost*.dll /usr/local/bin

The first ./configure creates the bjam program for MinGW, but then can't find it. On the second ./configure we tell it where the find bjam so it can complete the build. The modified user-config.jam file forces the suffixes used for library names to be what GNU Radio expect.

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 .stabs

When 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.

Errors using xmlto on Cygwin

Attempting to generate HTML documentation with xmlto on Cygwin may produce errors like

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 don't know if this is a Cygwin problem, a GNU Radio problem, or an xmlto problem. You can avoid this error by not installing xmlto or by removing or disabling it if it is already installed.

Cygwin binutils 20080523-1

Using Cygwin binutils 20080523-1 can cause a couple of problems. When building wxPython, you may get the error

ValueError: invalid version number '2.18.50.20080523'

and when building Numpy you may get errors like

Error: suffix or operands invalid for `fnstsw'

Eventually, these should be fixed by changes to wxPython and Numpy, but until the new versions are available the simplest workaround is to reinstall Cygwin binutils 20060817-1.

If you want to use binutils 20080523-1 (or if 20060817-1 is no longer available), you can make the following corrections to wxPython and Numpy: In wxPython edit the file /usr/lib/python2.5/distutils/cygwinccompiler.py to change the string "(\d+\.\d+(\.\d+)*)" to "(\d+\.\d+(\.(\d+))?([ab](\d+))?)" in three places; in Numpy edit the file numpy/core/include/numpy/fenv/fenv.h to change "int __status" to "short __status" in three places.

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.

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).

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)

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:

  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'

It is likely 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).

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:

$ ./configure ... --disable-gr-audio-oss --disable-gr-audio-windows ...

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

from gnuradio import audio

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

from gnuradio import audio

to import audio_windows, include the following lines

[audio]
audio_module: audio_windows

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:

from gnuradio import audio_portaudio as audio

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.

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:

usrp: failed to find usrp[0]
 [Python traceback appears here]
RuntimeError: can't open usrp1

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:

  [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

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.