Building gnuradio on windows with msvc

GNU Radio
1

Hey list,

I’ve got gnuradio building native on windows with MS visual studio using
cmake to generate the project file. Its not the whole gnuradio, just
gruel, gnuradio-core, and qtgui; as a demonstration.

I’d like to go over how to build, and some of the code changes that made
this possible.

Here is a screen cap for the quick preview. Its the qtgui waterfall:
http://i.imgur.com/iGPs3.png

– Grab the source code

Checkout the msvc branch on jblum.git
http://gnuradio.org/cgit/jblum.git/log/?h=msvc

– Install the dependencies

cmake, gsl, fftw, qt, python, numpy, swig, cppunit can be found
pre-built in zip files or exe installers
http://i.imgur.com/ynBha.png

qwt must be built from source once qt installed (see readme)

I could not find a pre-built guile, so I just installed it from cygwin
and added c:\cywgin\bin to my PATH

Of course, you dont need to install half these components if you dont
need swig or qt related stuff.

– Setup the environment variables

All of the installed packages will need to have their bin and lib
directories added to the PATH so they can be found at runtime. While
you’re at it, set the PYTHONPATH and PATH for the gnuradio install.

I recommend using rapid environment editor (vs the 40 character entry
box) so your eyes don’t bleed. Here is a screen cap of the PATHS all
setup on my system:

http://i.imgur.com/HyzgK.png

– Configure the project

Open cmake-gui and feed it the paths for the gnuradio source tree and a
path for the generated build file stuff. Click configure.

What happens next is an iterative process and you will wish there was
package config :slight_smile: Set the *_INCLUDE_DIRS and *_LIBRARIES variables for
various dependencies. As you set these variables and click configure,
check boxes for gnuradio components will appear once their dependencies
are met.

Here is a screen cap of my gnuradio configuration fully completed:
http://i.imgur.com/vOrOp.png

When you are satisfied, click configure if anything is in the red, and
then click generate. This will make a visual studio project file.

http://i.imgur.com/Jf9Es.png

– Build, test, install…

Open the gnuradio.sln

NOTE: Set the build mode to Release. Don’t mix debug and release
libraries. Many of the dependencies are built for Release mode only. If
you are going to build debug, make sure that all dependency libraries
are debug libraries. This includes python (if you want python support).

Right click on the BUILD_ALL target, click build
http://i.imgur.com/TRls9.png

Unit testing should work, right click on RUN TESTS, click build:
http://i.imgur.com/C8CdG.png

And to install, right click on INSTALL, click build.

– CMake related stuff.

If anyone is interested check out the CMakeLists.txt in gruel,
gnuradio-core, and gr-qtgui directories. Each component knows how to
check for its dependencies and register itself as a component.

Look at the gr-qtgui/src/lib/CMakeLists.txt as an example of a typical
component with swig + python. The gnuradio-core one can be a bit
daunting.

Theres also a modules directory that defines some functions and package
finding. The Gr* files define common-use functions for dealing with
python, swig, testing. The Find* files were snagged of the internet and
mucked up a bit to help deal with finding the dependencies when
pkg-config is not present.

http://gnuradio.org/cgit/jblum.git/tree/Modules?h=msvc

– The code, what changed?

  1. This was by far the hardest part. :slight_smile: When building with MSVC, its
    necessary to specify the linkage in header files when declaring things
    like class, structs, and functions.

To accomplish this, I created a header for each component that defines a
symbol export macro; And added this macro to the various header files
that needed it (in an automated fashion). Heres what they look like:

http://gnuradio.org/cgit/jblum.git/tree/gruel/src/include/gruel/api.h?h=msvc
http://gnuradio.org/cgit/jblum.git/tree/gnuradio-core/src/lib/general/gr_core_api.h?h=msvc
http://gnuradio.org/cgit/jblum.git/tree/gr-qtgui/src/lib/gr_qtgui_api.h?h=msvc

And an example of this macro in use:
http://gnuradio.org/cgit/jblum.git/tree/gnuradio-core/src/lib/general/gr_agc2_ff.h?h=msvc#n32

  1. Some source files used non-standard functions; most revolving around
    IO or math. The the easiest way to work around this was to make some
    compatibility headers for these sources to include:

http://gnuradio.org/cgit/jblum.git/tree/gnuradio-core/src/lib/general/gr_math_compat.h?h=msvc

http://gnuradio.org/cgit/jblum.git/tree/gnuradio-core/src/lib/io/gr_io_compat.h?h=msvc

  1. There is a small collection of missing header files.
    http://gnuradio.org/cgit/jblum.git/tree/msvc_compat?h=msvc

– OK, what now?

Well, if there is an interest in native windows support, I would be
happy to work with someone to port various components. Otherwise, the
work is as good as abandoned. No hard feelings.

The code changes will not break the build, the code is just more
general. So its actually safe to merge this kind of work (after some
cleanup, sure) back into the mainline. But thats up to Tom and the other
gurus.

Anyways, thats my new years gift to you all.
Happy new year!
-Josh

2

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

3

On 01/02/2011 08:21 AM, Moeller wrote:

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?

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 :slight_smile:

-josh

4

On 02.01.2011 22:38, Don W. wrote:

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).
Thanks, I will have to check this out. Will the UHD driver also work in
this environment?
I’m using the current SVN gnuradio.

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).
Cygwin is most GNU and POSIX/Linux compatible.
I had to modify some settings for Qt, qwt, qwtplot3d,swig etc.
But you can also use some prebuilt packages from the Cygwin-ports
repository
(Cygwin Ports)
You can use the Cygwin “setup.exe” on download packages from
cygwin-ports.
Recently I discovered the “apt-cyg” command-line installer for Cygwin,
also very helpful.

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 managed to build qtgui and grc, but usrp2 needs access to raw sockets.
That is on of the things Cygwin cannot emulate. On Windows there is a
similar thing
like http://www.winpcap.org/ , but that’s totally incompatible.
I hope with the UHD it will be better. UDP-sockets can be implemented in
a
platform-independent way.
With recent SVN versions of Gnuradio I didn’t have luck any more,
some Boost library issues. I did not have time yet for debugging this.

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.
With “Visual Studio Express” and SDK you can get a free version of the
MSVC and IDE.
I’m not willing to purchase the commercial version. I think the express
version is quite Ok for this purpose.
But the 64 Bit compiler is not supported directly (needs some tricks and
a special server SDK).
Current Cygwin has packages of a 64 Bit Mingw GCC compiler. This one
creates
native Windows binaries too. What about using the Cygwin environment to
create native Windows
executables? I used this method for years to create MATLAB Mex
functions.
MATLAB Mex DLL cannot depend on the cygwin DLL because of incompatible
exception handlers.
That’s why I used the Mingw-GCC instead of the Cygwin-GCC, both in a
Cygwin toolchain.

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.
It would be a good idea to support both build systems, if it’s really
possible.
I’ve seen this in the IT++ project. But even on Windows I’m using the
GNU toolchain,
because it’s all more comfortable. In the Cygwin bash shell you don’t
see much difference
between Linux and Windows machines. All my scripts are identical for
both operating
systems, exept some specific settings and environment variables.

5

Josh B. wrote:

experience with Mingw, but this gives you Windows native executables
a non-gnu compiler (MSVC here), then the end-developer will have an

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 :slight_smile:

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.