Re: [Discuss-gnuradio] Error when build GNU Radio using cywin64

[Craig Easton]

Tian Alvin has asked for some further info about my recent Windows build of GnuRadio, I though't I'd reply on-group as I guess there may be a few other masochistic individuale attempting to do this!

On Mon, 3 Aug 2015 11:26:09 +0100 Tian Alvin wrote:
> Thank you very much for sharing your experience. I will try to compile
> using Visual Studio.
> I've found a post about the instruction on installing GNU Radio on Windows 64.
> https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00284.html
> Is this the same steps as you were using? If not, could you please share
> the directions where I can find the guidance?

I ended up using multiple sources for help with the build as I had numerous problems. Both the build process, and GnuRadio itself seem to be very sensitive to previously installed software, and since I was building on a general development machine (e.g. multiple versions of Python already installed etc.), things got quite messy. Also it should be noted that my build is currently not perfect. I can only use the WX GUI (i.e. not the QT blocks), the audio output is choppy (this seems to be a common problem and isn't a major issues for me, but if anyone has got a fix for this on Windows I'd be interested to hear it!), and I also haven't enabled some components that I had problems compiling (but that I didn't need), specifically:

Version: 3.7.7.1
Components:
    ######################################################
    # Gnuradio enabled components                        
    ######################################################
      * python-support
      * testing-support
      * volk
      * sphinx
      * gnuradio-runtime
      * gr-ctrlport
      * gr-blocks
      * gnuradio-companion
      * gr-fec
      * gr-fft
      * gr-filter
      * gr-analog
      * gr-digital
      * gr-dtv
      * gr-atsc
      * gr-audio
      * * portaudio
      * * windows
      * gr-channels
      * gr-noaa
      * gr-pager
      * gr-qtgui
      * gr-trellis
      * gr-utils
      * gr-wxgui

    ######################################################
    # Gnuradio disabled components                       
    ######################################################
      * doxygen
      * gr-comedi
      * gr-uhd
      * gr-video-sdl
      * gr-vocoder
      * gr-fcd
      * gr-wavelet
      * gr-zeromq

Some of the resources I used are listed below, but I'd advise caution when referring to them. They are *extremely* useful, (and I'm very thankful that various individuals have taken the time to create them), but some of the "facts" they quote are not true, or at least not true any more, (not for my 3.7.7.1 build anyway), so take everything with a pinch of salt, including what's in this reply! :-), and confirm everything yourself.

https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00284.html

https://www.liamschneider.com/node/9

http://voltronics.blogspot.co.uk/2013/01/gnu-radio-windows-build-guide.html

http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows?version=94
(Useful info about the prerequisites, this doesn't cover the actual compilation).

https://gnuradio.org/redmine/projects/gnuradio/wiki/MingwInstallMain
(Again useful for general background info and the list of prerequisites but not the compile itself as I ended up using VisualStudio instead).

http://www.lfd.uci.edu/~gohlke/pythonlibs/
(An invaluable resource for Windows binaries of Python modules)

There were others I can't remember! I basically Googled "gnu radio compile on windows" (and other variations), then walked through the results picking off interesting points, comments from blogs, etc.

Some general hints from my experience of the build, (when 3.7.8 gets a full release, and if I can find the time, I may attempt the build from scratch again this time documenting the process properly, but for now):

1) There are a *load* of pre-requisite installs before you can start the build. I found determining what is actually required manually (rather than taking the various walk-throughs at face value, particularly about version numbers), to be more beneficial. This process is painful, but repeatedly attempting the CMAKE config (cmake-gui), then finding the required packages one by one is possible, and you gain a much better understanding of the dependences this way.

2) Getting all the correct Python modules installed was a bit of a pain. I'm not a Python person so I had fun with this! "pip" is your friend here! My current module list is as follows (NB: not all of these may be required for GnuRadio, but most of them were installed one way or another for this build):
 C:\Python27>pip list
 alabaster (0.7.4)
 Babel (1.3)
 cheetah (2.4.4)
 colorama (0.3.3)
 docutils (0.12)
 Jinja2 (2.7.3)
 lxml (3.4.4)
 markdown (2.6.2)
 MarkupSafe (0.23)
 numpy (1.9.2)
 pip (7.1.0)
 pycairo (1.8.10)
 pycairo-gtk (1.10.0)
 Pygments (2.0.2)
 pygobject (2.28.6)
 pygtk (2.24.0)
 PyOpenGL (3.1.1a1)
 PyOpenGL-accelerate (3.1.1a1)
 PyQt4 (4.11.3)
 PyQwt (5.2.1)
 pytz (2015.4)
 pyzmq (14.6.0)
 setuptools (17.1.1)
 six (1.9.0)
 snowballstemmer (1.2.0)
 Sphinx (1.3.1)
 sphinx-rtd-theme (0.1.8)
 wxPython (3.0.2.0)
 wxPython-common (3.0.2.0)
 C:\Python27>

3) CMAKE seems pretty poor at working out what you have installed and where it is (at least on Windows). Much of my initial build problems were related to getting the CMAKE config correct, I seem to remember telling cmake about the boost libraries being particularly troublesome!

4) The command search path is *very* important, both during the builds and when running GnuRadio. It really shouldn't be so sensitive, but I found that even the ordering of the command search path can cause quite different behaviours. (Don't forget PYTHONPATH either).

5) Use cmake-gui.
This makes it much easier to work out where cmake is having trouble. You can easily inspect each of the required parameters, and as you correct more and more of them, new parameters that are required will appear so you can either install the dependency or manually assign the correct value (if this isn't done for you).

6) See my bug report here: https://gnuradio.org/redmine/issues/799
Once you have got to the point where CMAKE has generated all the VisualStudio projects and a solution file, you will find that many of the projects won't compile unless you make the edit detailed in this bug report. Once you have done this, re-run the the CMAKE config again, generate the build files, then try a full build in VisualStudio.

7) Unless you are very lucky, even when you have GnuRadio compiled and installed, it probably won't run, or at least some of the blocks won't work (at least that was my experience). The current version of GnuRadio drops you back into the world of ""DLL hell" on Windows (at least it did for me). GnuRadio (and all of it's components) will scan though your search-path for required DLLs, if it can't find what it expects, or finds an incompatible DLL earlier in the path, things will break. The SysInternals ProcessExplorer is your friend here. You really shouldn't have to do this sort of thing in this day and age, but monitoring the python process for file activity as you run GnuRadio (or run problematic graphs in GnuRadio) will highlight any missing (or incorrectly loaded DLLs). If you find any you can then either install the missing components, move the correct DLL to one of the earlier search locations (e.g. within the GnuRadio install tree), or perhaps add entries (or re-order your command search path) so the correct DLL is found when needed.

As I've said before, this process was incredibly painful and had a very steep learning curve for me. It probably took me about two weeks on and off before I got GnuRadio running to the point where I could use my HackRF blue. I had no intention of compiling everything from scratch originally, I just couldn't find a pre-compiled Windows binary that worked reliably with the blocks I needed so I was forced to attempt it. GnuRadio *really* needs a proper Windows (binary) installer (with blocks like gr-osmosdr included) that is independent (as much as is possible) of other installs.

Regards,
Craig.