GNURadio Win64 Binaries

Download Latest GR 3.7 Installer (GR

Download Latest GR 3.8 Installer (GR py3.9) 

Download Latest GR 3.9 Beta Installer (GR

Download All Other Binaries

Documentation, Known Issues / Change Log


GNURadio is a powerful SDR tool, however it’s biggest limitation has always been that it is a challenge to install, even on Linux systems, because of the large number of shared dependencies.  If you are a daily Windows user there is an even larger problem because most of these dependencies are also very Linux focused and difficult to build/install on windows for the average Windows users who is accustomed to simply double-clicking “setup.exe”.  Using a Linux VM is problematic with SDR because of the high demands that are placed on the USB interface.  This leaves the user with dual booting, limiting them to one environment or the other.  So the goal of this project was to build an optimized GNURadio binary using the most recent compiler for all dependencies, and packaging the result in an easy-to-use .msi package.

Results :

Here are the packages currently available.  Every ounce of code above what is provided by Windows and the C runtime was built from source.  MSVC 2015 (3.7) or 2019 (3.8) Community Edition was used to build 64-bit binaries.  Three versions are currently provided, one for all machines with debug symbols for the GNURadio code, the second performance-optimized for only for machines with AVX2 extensions (Haswell+).  The second may be marginally faster, but this has not been validated at this time.  And finally, a package where the entire stack was built in Debug mode for complete symbol coverage all the way down the stack to core Python.  This should only every be needed in the most hairy bug-seeking quests.

For users that wish to experiment a bit more, there are two additional options available.  The build scripts themselves can be downloaded on github here, and these scripts allow two choices, either a full build from scratch as was originally accomplished (a long and tedious chore) or for those that would like to focus on just GNURadio, the package of dependencies can be automatically downloaded as binaries and then GNURadio built against those.

Whats Included :

GNURadio was built with all CMake options enabled including GRC, with the exception of gr-comedi which is based on Linux-only libraries. 

GNURadio was built with all CMake options enabled as well (gr-comedi no longer part of 3.8).  This version still includes Python 2.7, and is expected to be the final version to do so

Python 2.7.10 was built from source using VS 2015 as are all required packages.  The Intel compiler was used to build the Fortran modules in SciPy.  See notes below.

Starting with py3.9, Python 3.9 was built using VS 2019 and packages were installed using vcpkg and pip install.

Ettus UHD drivers were built from source and are included.

Osmosdr was also built from source, with support for most of the SDR drivers, including the RTL2382 / HackRF / BladeRF / AirSpy / SoapySDR / Funcube Dongle.  Some of the less used drivers may be included in future builds, please send feedback if there is a particular osmosdr driver you’d like to be priority.

A wide variety of OOT modules are included (note: some of the below are not in the 3.8 build as they are not yet 3.8 compatible at time of packaging):


The binaries should work with: 64-bit Windows 7/8/10.

Has been tested on Windows 7 and Windows 10, in both a “clean” configuration and a “busy” developer environment. Windows 8 is untested.

The scripts were designed for a Windows 10 / MS Server 2016 environment.

Prerequisities :

None to install via binary.  To use the future build-from-source options, VS 2015, Wix, Git, Doxygen, CMake 3.13, and ActiveState Perl must be installed.  An Intel Fortran compiler is optional.

How to Use:

See Documentation


This is merely a re-package of source code built by others, and is provided free of charge under the GNU licenses of each individual source package, without any guarantees or support.  Please post questions/issues to the Gnuradio mailing list here, and if possible, please verify if the problem only occurs in this Windows installation of gnuradio or is shared with the standard Linux install so the team there can budget their time accordingly.


Initially it seemed like a good idea to try to build this using static libraries to the maximum extent, in order to avoid the “DLL Hell” problems that can occur with applications with many dependencies.  However, in the end that may not be the best approach, and for many of the major libraries, I reverted to shared libraries.  This is in part because of the way Python code calls into C++ libraries, then other C++ libraries also call into the same code. You end up with some extremely large DLLs with multiple copies of the same underlying library (Qt being the big one I’m referring to), and potentially adding bugs rather than eliminating them.  Nevertheless, in the future it would be useful to consolidate where it’s possible, particularly on Windows where most of the dependencies are not used by any other applications.

The Python build needs some further explanation. A decision I made was to compile every line of code with the same / newest compiler, the goal being to get the highest possible performance out of my hardware.  However, this goes against the Python standard… Python is known to be particular about consistent compiler use, so has established a de facto standard for pre-compiled modules for each version of Python.  Python 2.7 is intended to be built with MSVC 2008, not 2015. Because this project was consistent in using VS 2015, this is fine internally to our use, but raises 2 potential problems: 1) A user might install a binary package from the web to extend this installs functionality.That binary will likely be built with VS 2008 and could have errors.  2) A user might use this version of Python as their “primary” python and run into unexpected compatibility issues.

As a result, the Python included in this binary is intended only for use with this GNURadio build, not general use, and users should use care if installing additional binary packages to it.  Python-only packages or user-built packages should be fine (if built w/ MSVC 2015).  Python users may notice the installation is not a virtualenv, this is simply because the installation does not know if the user has a system python installed (unlike Linux, python is often not installed at all), and we certainly don't want this python loaded as the system version. 

The build process itself was not straightforward, several weeks of part-time work… certainly required far more libraries than I expected to get “everything” built from source.  There were significantly more issues with the source code provided than I expected to have to fix.  Those fixes will be documented here for user’s reference, and bug reports submitted where applicable.


1-       Create a windows compatible version of gr-newmod to allow easier creation of custom modules in windows