Compiling WSPR on Windows and Linux

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 ./configure, then make, then 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 ‘2.18.50.20080109’”. 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 msvcr71.dll (gccmrt 71), and built WSPR again. This did the trick. Now my build of WSPR works.

Advertisements

3 Responses to Compiling WSPR on Windows and Linux

  1. Pingback: Remote WSPR and Quisk on a Nettop Computer « Eclectic Technical Experiences

  2. Greg Cook says:

    Hi,
    Am also trying to compile wspr on XP, and have downloaded all the compilers etc. I am confused as to how to make the build. Don’t know which makefile to use. The svn download gives me a ‘trunk’ and ‘wspr’ dir, with different makefiles in each. Have tried:

    > cp makefile.mingw makefile
    > nmake

    But it fails on a piece of ‘{‘ syntax…

    Could you help me with the build?

    Thanks

    Greg g4cui

  3. WA3YAY says:

    I followed George’s wiki and was having success on my old AsusEee notebook runing EasyPeasy Linux 1.6 (Ubuntu) until the make failed with an error 1. Sadly, I just don’t have the time right now to work through the problem. As you so correctly characterized it, not “trivial” build process.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: