GNURadio
Win64 Binaries
Download Latest GR 3.7 Installer (GR 3.7.13.5)
Download Latest GR 3.8 Installer (GR 3.8.2.0 py3.9)
Download Latest GR 3.9 Beta Installer (GR 3.9.0.0)
Documentation, Known Issues / Change Log
Background:
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.
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.
GNURadio
3.7.13.5 was built with all CMake options enabled including
GRC, with the exception of gr-comedi which is based
on Linux-only libraries.
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 3.8.2.0 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.
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.
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