WindowsInstall

= Windows Installation =

Binary Installers
There are a few different unofficial GNU Radio binary installers that are maintained by the community:

1) Geof Nieboer's installer hosted at gcndevelopment.com. This is a binary installer for 64-bit Windows 7/8/10 that includes all dependencies for Windows, a custom python distro, commonly used SDR drivers, and several OOT blocks.

2) Radioconda installer. This binary installer tends to be the most up-to-date but currently includes fewer SDR drivers and OOT modules. It utilizes the  package/environment manager and provides easy access to thousands of Python and other packages that are not strictly related to GNU Radio. This also lets you stay up-to-date without having to re-install. Since this provides the same conda-forge packages available without the installer, the conda install guide might be useful for additional instructions, including how to build OOT modules from source.

3) Pothos SDR development environment installer. This binary installer includes GNU Radio, Pothos, CubicSDK, and other tools. It has historically been updated about once or twice per year.

Current Windows Status
Installing core GNU Radio and USRP on Windows is becoming more routine. Many OoT modules may still require compiling locally. Please report any success or failures. Patches and enhancements are especially welcome!

Windows Porting Issues
Considerable effort has been put into making the GNU Radio code portable among various operating systems, but there are several reasons why it cannot be &quot;simply&quot; compiled and run under Windows:


 * The build and install procedures are based on Linux scripts and tools
 * Several third-party libraries are used, each with its own, often system-dependent, installation procedure
 * Most GNU Radio applications must interface to hardware (e.g., a sound card or USRP) which require system-dependent drivers and installation procedures
 * Because GNU Radio is written as an extension to Python, there are potential problems on Windows if different runtime libraries are used for GNU Radio and Python

The following sections show how these issues can be addressed.

Installation Options
GNU Radio is designed to be flexible. It has a number of modules, capabilities, and options that can be enabled or disabled to suit the needs of the user, and the user can add custom blocks or modules to the system.

To support this flexibility, it comes with a set of files and scripts to be used with GNU software build tools (sh, make, autoconf, automake, etc.). These tools use Linux-like commands and filenames that are not normally available on Windows systems.

Fortunately, we are not the first to face this problem, and several solutions exist. These are presented in order of increasing difficulty:

Building on Windows with Native Tools
Ettus Application note describes how to build from source. Similar is a post at for OOT modules.

Powershell scripts are now available at https://www.github.com/gnieboer/gnuradio_windows_build_scripts that fully automate the build process for GNURadio 3.7.9.2+. A few build dependencies are required (MSVC 2015, Git, Doxygen, CMake, Perl, Wix) but all are free. The script has two options:


 * 1) Build all dependencies from source (including python itself)
 * 2) Download a prebuilt custom dependency package and then build only GNURadio and a few OOT modules on top.

The binary installers described above are built with these scripts. They ensure that all dependencies are built with the same toolchain against the same runtime libraries, and handle the patches and configuration &quot;tweaks&quot; needed to build them on Windows.

If option 1 is desired, note that to build scipy, the non-free Intel Fortran compiler is required, gfortran cannot build objects that can link with MSVC C objects. If you do not have said compiler, the scripts will download pre-compiled wheels instead.

More information on the build process is available on the GitHub repo readme, and also at http://www.gcndevelopment.com/gnuradio.

GNURadio 3.6 has also been compiled on Windows using native tools as well (see http://voltronics.blogspot.com/2013/01/gnu-radio-windows-build-guide.html and https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00284.html)

More helpful tips on dependency version information have been reported:

https://lists.gnu.org/archive/html/discuss-gnuradio/2013-12/msg00497.html

MinGW/MSYS
MinGW (http://www.mingw.org/) provides GNU compilers and Window-specific header files for compiling native Windows applications.

MSYS (http://www.mingw.org/msys.shtml) is a companion set of Linux-like commands, shell, and build tools.

MinGW does not include a Linux programming interface; programs should be smaller and faster than with Cygwin (in theory), but will require more Windows-specific code.

MSYS is intended primarily as a build environment, making it more compact than Cygwin.

Because there is no Linux API emulation, GNU Radio built with MinGW should be used with standard Windows versions of Python and the third-party libraries.

MinGW does not provide as much support as Cygwin for installing third-party libraries, but in many cases precompiled binaries are available.

For detailed installation instructions using MinGW and MSYS see Installing GNU Radio with MinGW.

Cygwin
Cygwin (http://www.cygwin.com/) is a Linux-like environment for Windows.

It provides the Linux-like shell, file naming, and build tools we need and also makes it easy to install many of the third-party libraries required by GNU Radio. It also provides a Linux programming interface (API); this is not required by GNU Radio, but it lets us use the better-tested Linux versions of some functions.

Because the Linux API uses its own C runtime library, it is best to use Cygwin versions of Python and the third-party libraries when building GNU Radio with Cygwin.

For detailed installation instructions using Cygwin see Installing GNU Radio with Cygwin.

Chocolatey
To quote from the [|https://chocolatey.org/ Chocolatey homepage]: Chocolatey NuGet is a Machine Package Manager, somewhat like apt-get, but built with Windows in mind..

There are packages for gnuradio (and its dependencies) available in a separate repository (currently the best known source is: https://github.com/ariovistus/chocolatey-packages)

To install, open an Administrative command line session and run:

iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

Now you need to install a source which has the recipes for gnuradio and dependents. The easiest method is to clone the chocolatey-packages from the github repository listed above (https://github.com/ariovistus/chocolatey-packages), then add the local source from within an Administrative command line session:

choco source add -name gnuradio -source C:\&lt;path-to&gt;\chocolatey-packages

Create the numpy package:

cd \chocolatey-package\numpy cpack

Create the gnuradio package:

cd \chocolatey-package\gnuradio cpack

Now install the gnuradio package:

choco install gnuradio

Follow the command prompts.

WSL | Ubuntu
Enable WSL from windows features. Install Ubuntu 20.04 (or newer) from Microsoft Store. Using the Ubuntu terminal, install gnuradio as you would on linux. If you want to develop GNU Radio's core you will need to build GNU Radio from source.

WSL 1/2 (before WSLg)
Install additional package "libgtk-3-dev" sudo apt install libgtk-3-dev WSL 1 and 2 (before WSLg) do not have an X server for displaying graphical applications. Install an X server, either VcXsrv or Xming  as WSL does not come with an X server. VcXsrv is recommended as it is open source and self-contained instead of being tied to Cygwin, whereas Xming "asks for donations" to the developer as a dubious "sale" for non-existent support.

Launch VcXsrv, making sure to select "Disable access control" option in the Extra settings so that any application can export to X11. Edit bashrc to set up the display by adding the following lines at the bottom of the file.

WSL1:

# X11 forwarding for Windows export DISPLAY=:0.0 export LIBGL_ALWAYS_INDIRECT=1

WSL2:

# X11 forwarding for Windows export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0 export LIBGL_ALWAYS_INDIRECT=1

Restart the Ubuntu terminal and run gnuradio-companion

WSLg
Currently in early testing stages, the WSLg update contains a Wayland graphics server and X interface layer allowing graphical applications to run without extra setup.

From the Ubuntu terminal run gnuradio-companion

Using an Azure VM
Another way to generate a GNU Radio environment if you're using Windows, is to create an Azure Virtual Machine running Ubuntu Server 18.04 LTS.

If you already have an existing Azure account you can follow the instructions here to create an Ubuntu VM using the Azure portal. Otherwise, you can sign up for an account here. Azure provides free accounts for students with a limited set of credits.

Once your VM is created you should be able to SSH into it, to install a desktop environment. Full instructions can be found here, but in summary: Install xfce sudo apt-get update sudo apt-get -y install xfce4 Install xrdp as a remote desktop server sudo apt-get -y install xrdp sudo systemctl enable xrdp Configure xrdp to use xfce echo xfce4-session >~/.xsession Restart the xrdp service sudo service xrdp restart You will need to create a local password for your Linux VM (on top of your existing SSH key), and open port 3389 on the VM.

Finally you can use a remote desktop client, such as Remote Desktop Connection to connect to your VM and follow the instructions for GNU Radio on Ubuntu found here.

Known Windows Build Issues
So far, we have workarounds for all reported problems:


 * I got the following error after a clean install "This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.". I fixed this by finding qwindows.dll on my PC (for me it was in C:\Program Files\GNURadio-3.8\bin\platforms\), creating a new directory C:\Program Files\GNURadio-3.8\bin\plugins\platforms, and copying the 4 DLLs to C:\Program Files\GNURadio-3.8\bin\plugins\platforms (I had to create the "....plugins\platforms\" sub-directory). I'm sure there's a more elegant fix, but this seems to work.