Compiling WSPR on Windows and Linux
November 20, 2010 3 Comments
The first step in trying to add frequency hopping to WSPR is to be able to compile the program myself. Joe Taylor, the program’s author, wrote a web page on how to build WSPR, but it is not very detailed; the web page helped, but I still struggled quite a bit. WSPR is written in a combination of Fortran (most of it), C, and Python, and it uses several libraries, so it is not a trivial program to build.
The code is stored on a public SVN server, so downloading it was not a problem; I used Eclipse do do that (and to edit the sources later).
I started on Windows. I already had Python and MinGW (the C compiler) installed. I installed G95 (the Fortran compiler) and tried to build the program, using the included makefile. It did not work. There were many messages, and I could not tell which ones were errors and which ones were warnings. I quickly gave up and decided to try my luck on Linux, where it is often easier to build open-source codes.
I started by installing on Ubuntu all the software pieces that were potentially missing, as listed on Goerge Smart’s wiki:
sudo apt-get install python2.6-dev python-numpy python-imaging-tk python-pmw libportaudio2 portaudio19-dev libsamplerate0-dev gfortran cl-fftw3. George’s command line also included subversion, but I already had a working SVN client in Eclipse. (Update from Jan 21st, 2011: on another machine I also had to install g++; if you don’t have g++, the configure script works, but the build fails with a strange message from libtool.)
At this point, I typed
make install. No errors, so the build was complete. Very easy.
I tried to run the program. WSPR changes the radio’s frequency using a command-line utility called rigctl, which was missing. It is part of a library called hamlib. I tried to install hamlib using apt-get, but there is no ubuntu package for it. I downloaded the sources, built and installed the library. Now there was rigctl, but it was not working; it didn’t find it’s dynamically linked library,
libhamlib.so.2. It turns out that you need to a file
local.conf containing the line
/usr/local/lib to the directory
/etc/ld.so.conf.d, and then run
ldconfig. This tells Linux where to find hamlib’s dynamically-linked library. Now rigctl works.
It works, but it does not support the Softrock. A little digging into the sources of hamlib revealed that it only compiles the Softrock support if a library called libusb is installed. Istalling libusb-dev with apt-get and then building and installing hamlib again fixed the problem. Now rigctl supports the Softrock.
But it still did not manage to actually change frequencies. It turned out that the Linux kernel did not manage to recognize the Softrock’s USB interface. I was running Linux under VirtualBox, and for some reason Linux was able to see the USB device, but not to communicate with it.
This is when I gave up and decided to try Windows again.
On Windows, the build crashed with a message f2py crashes with a message “ValueError: invalid version number ‘18.104.22.16880109’”. Digging into the python source that generated this message revealed that it does not like the final .20080109 in the version of binutils (e.g., that’s what “ld –version” returns). It’s not that it thinks that this version is broken, it just does not like the 4-part version number. At this point I realized that the Python code that builds Fortran and C libraries for use with Python is quite sensitive to the version of MinGW you use. I tried to find an older version of MinGW to try but I didn’t find any.
I then discovered that somebody else who faced the same problem, Giovanni Bajo, created a distribution of MinGW that is known to work with Python. I installed it, and together with version 4.1.2 of G95 and Python25, it almost worked.
Almost, because the linker could not find the library file for the argument
-lwinmm. I found out that there is a
libwinmm.a in the MinGW
lib directory, so I replaced
-llibmm with the path to this library file. Now the build finished with a binary.
When I tried to run WSPR, it crashed immediately. I have Visual Studio installed, so the crash caused Windows to offer me to debug the code. The debugger showed that the crash was inside the C run time library,
msvcr71.dll. I remembered that this MinGW distribution contains a utility to tell the compiler which run time library to use; I ran it with an argument that tells it to use
gccmrt 71), and built WSPR again. This did the trick. Now my build of WSPR works.