Binary builds for Windows

[Victor Joukov]

Guys,

it's looking great and I'm excited to try it. But my last attempts to build such complicated piece of software (I tried and failed with GNU Radio) took so much time that I'm wary to try this myself.

I would appreciate a binary build for Windows as it would lower the barrier to try such nice and useful software.

If you also could provide drivers for HackRF I would be just happy.

Thanks,

Victor.

[Josh Blum]

On 03/23/2015 10:34 PM, Victor Joukov wrote:
> Guys,
>
> it's looking great and I'm excited to try it. But my last attempts to build
> such complicated piece of software (I tried and failed with GNU Radio) took
> so much time that I'm wary to try this myself.
>

Fortunatly, the core of pothos + graphics is very low on dependencies.
To install the basics (main library, gui, widgets, and core blocks), you
will probably have an easier time. You only need CMake, a recent version
of MSVC, and qt5 development package. Other dependencies are optional.
Also you will probably want libhackrf and soapysdr as well (given your
comment below) -- and that drags in boost (so sorry!).

https://github.com/pothosware/pothos/wiki/BuildGuide

However, if you want to use blocks from gnuradio, you still have to
actually build gnuradio (which is heavier on the dependencies). I guess
you could skip the graphics packages though:

https://github.com/pothosware/gnuradio/wiki

In any case, if you do decide to compile, don't hesitate to send any
build errors this way. :-)

> I would appreciate a binary build for Windows as it would lower the barrier
> to try such nice and useful software.

I totally agree. I guess that I have put it off in favor of development,
and the barrier to setting up automated build and packaging stuff. All I
can say is that installers are coming, I need them for some upcoming
demos. Its just on a timespan of a month or two.

>
> If you also could provide drivers for HackRF I would be just happy.
>

Are you asking for Hack RF support in general? or specifically windows
binaries for the hackrf?

In general hackRF is supported through the osmo support module in
SoapySDR: https://github.com/pothosware/SoapySDR/wiki
https://github.com/pothosware/SoapySDR/tree/master/OsmoSupport

When windows packages are available, I will try my best to build for all
of the host-based devices available through SoapySDR (that will build
under MSVC).

I would like it if someone would volunteer to make a Soapy SDR module
directly on top of libhhackrf. This would save the osmo wrapper and the
boost dependency. Then it would be even cooler if hardware vendors
provided windows installers + prebuilt soapy sdr modules for each
device. :-P

Thanks!
-josh

[Victor Joukov]

Thanks Josh.

Believe me, I value your efforts very much and I understand the trade-off between feature development and packaging.

My main problem with CMake-based builds is that CMake does not pay attention to the specific compiler I try it to use. I have a computer with several versions of MSVC installed and despite using vsvars.bat for specific compiler it insists on using something it dug up from registry. The same story with boost - it picked up another compiler - Visual Studio 2011.

So I failed to even begin building GNU radio. And their requirement - Visual Studio 2010 - is different from yours - C++11 which I think is available only in Visual Studio 2013. Were you able to build GNU Radio with more modern compiler than 2010?

How extensive is the interface for device I should implement on top of libhackrf? I counted around 20 sensible libhackrf functions (not accounting for maintenance - reflashing the firmware which does not work for Windows anyways), trying to understand what is to implement in SoapySDR for them.

Best,

Victor.

[Josh Blum]

>
> My main problem with CMake-based builds is that CMake does not pay
> attention to the specific compiler I try it to use. I have a computer with
> several versions of MSVC installed and despite using vsvars.bat for
> specific compiler it insists on using something it dug up from registry.

Thats unfortunate. When I configure a project under windows, I usually
get a drop down to select the compiler like this:

https://i.imgur.com/bXhdB4V.png

Its worked in the past, but, I dont have multiple msvc versions
installed ATM to test against.

> The same story with boost - it picked up another compiler - Visual Studio
> 2011.

You have my sympathy here. Even on linux systems the FindBoost.cmake is
a strange script. Most Find*.cmake scripts will let the user override
the specific include path and library. The Boost one likes to overwrite
all of the user's -DBoost_* flags that they pass in.

I think there is a correct magic incantation, I just remember it ATM.

>
> So I failed to even begin building GNU radio. And their requirement -
> Visual Studio 2010 - is different from yours - C++11 which I think is
> available only in Visual Studio 2013. Were you able to build GNU Radio with
> more modern compiler than 2010?
>

MSVC 2010 was just not complete enough, so theres a minimum requirement
of MSVC 2012 for the C++11 support. And MSVC 2013 C++11 support is even
more complete and should also work. FWFW, I have been building with 2012.

That said, I'm surprised to hear that GNU Radio has an issue with more
recent MSVCs than 2010. I havent built GNU Radio on windows in a while.
I guess I will give it a shot myself and see what happens.

> How extensive is the interface for device I should implement on top of
> libhackrf? I counted around 20 sensible libhackrf functions (not accounting
> for maintenance - reflashing the firmware which does not work for Windows
> anyways), trying to understand what is to implement in SoapySDR for them.
>

Just to be clear, you shouldnt have to write a soapy sdr module for hack
rf. If you tell SoapySDR's cmake configure where boost is and where
hackrf libs/headers are, it should build support through the osmo
support module. The verbose from the cmake configure will let you know
if it work.

However, if you are interested in building a Soapy SDR module for the
libhackrf (without the in-between osmo wrapper). That would be really
awesome. Essentially, you write a SoapySDR::Device class and fill in all
of the overloads with calls into libhackrf.

Some documentation here:
https://github.com/pothosware/SoapySDR/wiki#driver-api

Theres also links to some other existing drivers if you want to look at
other examples (see NovenaRF and EVB7 links under Support Modules on the
side panel): https://github.com/pothosware/SoapySDR/wiki

And the hackrf source/sink for osmosdr is a good example of usage of the
hackrf library for this purpose:
http://cgit.osmocom.org/gr-osmosdr/tree/lib/hackrf

-josh

[Josh Blum]

Quick update, here is what worked for me:

###################################################################
## Boost on windows
###################################################################
If I install boost libraries from:
http://sourceforge.net/projects/boost/files/boost-binaries/1.57.0/

I have to tell cmake the following variables and it figures out the rest
correctly:

* BOOST_ROOT=C:/local/boost_1_57_0
* Boost_LIBRARY_DIR=C:/local/boost_1_57_0/lib64-msvc-11.0/

###################################################################
## GNU Radio windows fixes
###################################################################
For the most part there were minor windows fixes (mostly for volk). I
have put them up on the pothos branch of gnuradio. I didnt build every
component but I did build the core stuff:
https://github.com/pothosware/gnuradio/commits/master

###################################################################
## Remaining swig issue
###################################################################
Swig does work on my setup. I use it for the SoapySDR python bindings.
But for some reason the GNU Radio swig build bombs out "msb6006 exited
with code 9009". Maybe the swig invocation command is too long. I am
curious what happens (if you also try this out).

Anyhow, for the pothos use-case, we dont need swig, just the grc block
definitions. Unfortunately the GNU Radio build system makes the two hard
to separate. So I may end up with some build system mods to install grc
blocks without swig. It would save some compile time too! but ideally I
should figure out this swig issue.

-josh

[Victor Joukov]

Josh,

thanks for helping me. I will try to build GNU Radio with Visual Studio 2013 Community Edition.

And after that, I'll try Pothos.

And I was interested in how hard to write a direct wrapper for hackrf. I did not build libhackrf myself though, so it's another task.

[Josh Blum]

>
> ###################################################################
> ## Remaining swig issue
> ###################################################################
> Swig does work on my setup. I use it for the SoapySDR python bindings.
> But for some reason the GNU Radio swig build bombs out "msb6006 exited
> with code 9009". Maybe the swig invocation command is too long. I am
> curious what happens (if you also try this out).
>

It turns out that GNU Radio has a customized UseSWIG.cmake that is
causing this trouble. Removing it fixes the build issue:

https://github.com/pothosware/gnuradio/commit/30fa4b26c9447bcb36e442d435a575f7925f88d6

-josh