Re: Building with CMake on Win7 with MSVC 2008

GNU Radio
1

OK, so here’s what I’ve done to get it to build:

  • To build gnuradio-core, comment out lines in
    D:\gnuradio\src\gnuradio-3.3.0\gnuradio-core\src\lib\io\CMakeLists.txt
    #${CMAKE_CURRENT_SOURCE_DIR}/gr_stream_pdu_base.cc
    #${CMAKE_CURRENT_SOURCE_DIR}/gr_stream_pdu_base.h
    #gr_tuntap_pdu
    #gr_socket_pdu

  • Remove
    #include <gr_pdu.h>
    #include <gr_tuntap_pdu.h>
    #include <gr_socket_pdu.h>
    %include “gr_pdu.i”
    %include “gr_tuntap_pdu.i”
    %include “gr_socket_pdu.i”
    from D:\gnuradio\src\gnuradio-3.3.0\gnuradio-core\src\lib\io

It seems that these new modules (added to git 5 days ago) don’t play
nicely
with CMake on windows (the libraries required only exist on Linux
anyway)

  • To build gnuradio-audio, add #include <io.h> to
    audio_portaudio_source.cc
    and audio_portaudio_sink.cc

  • Add boost.Chrono library input to linker missing from projects:
    fcd_nfm_rx
    dial_tone
    _filter_swig
    _fft_swig
    _fcd_swig
    _pager_swig
    _digital_swig
    _vocoder_swig
    _blocks_swig
    _audio_swig
    _analog_swig

With these modifications, it builds on MSVC 2008.

I am now getting issues with RUN_TESTS - they all seem to fail. However,
after running the INSTALL build and testing in Python, it seems like
most
things work. How can I ascertain the causes of these test failures?

My main objective with this was to get the portaudio source working - I
believe this was not compiled with the precompiled binaries from Ettus
Research, which is what started me off compiling in the first place. The
audio sink appears to work fine, but the audio source does not:
audio_copy.py simply exits after the call to run(), without an error
message (there are a couple of complaints about invalid arguments to
gr_vmcircbuf_default_factory, but that usually doesn’t stop the whole
thing
from working). Does anyone know how I can debug this?

2

On 12/12/2012 07:40 AM, wakjah ’ wrote:

#include <gr_pdu.h>
#include <gr_tuntap_pdu.h>
#include <gr_socket_pdu.h>
%include "gr_pdu.i"
%include "gr_tuntap_pdu.i"
%include "gr_socket_pdu.i"

from D:\gnuradio\src\gnuradio-3.3.0\gnuradio-core\src\lib\io

It seems that these new modules (added to git 5 days ago) don’t play nicely
with CMake on windows (the libraries required only exist on Linux anyway)

It seems like some unstable stuff was merged into master. Can you post
the error? I understand the tuntap issue. But I’m not sure about the
others…

  • To build gnuradio-audio, add #include <io.h> to audio_portaudio_source.cc
    and audio_portaudio_sink.cc

can you post the patch?

http://gnuradio.org/redmine/issues/495

_blocks_swig
_audio_swig
_analog_swig

With these modifications, it builds on MSVC 2008.

Interesting, I think one of the boost dependencies pulls in another
boost dependency that we dont normally link against. My reference is
boost 1.47.

What version of boost are you using?

Can you post the patch for this?

I am now getting issues with RUN_TESTS - they all seem to fail. However,
after running the INSTALL build and testing in Python, it seems like most
things work. How can I ascertain the causes of these test failures?

Usually its an issue of something missing from the %PATH%. The test
scripts attempt to set the environment variables so that in-tree build
products are in the PATH, but probably not out of tree dependencies. It
may be good to run dependency walker and see what is “missing”

My main objective with this was to get the portaudio source working - I
believe this was not compiled with the precompiled binaries from Ettus
Research, which is what started me off compiling in the first place. The
audio sink appears to work fine, but the audio source does not:
audio_copy.py simply exits after the call to run(), without an error

I think the windows audio source implementation is empty!
http://gnuradio.org/redmine/issues/496

message (there are a couple of complaints about invalid arguments to
gr_vmcircbuf_default_factory, but that usually doesn’t stop the whole thing
from working). Does anyone know how I can debug this?

That print is safe to ignore.

-josh

3

Actually, I’m not sure that it was strictly necessary to remove all of
those from the make list; I just removed what I thought was affecting
it
(anything that referenced if_tun.h - even if it was within a #if/#endif)
and it seemed to work.

With regards to posting patches… yes, I can, but I’m not sure how. I
understand that I need to use git format-patch, but do I have to commit
beforehand? I thought the idea was that I would create a patch and
submit
it, and then someone would commit and merge the patch later on, but I
can’t
see how to get format-patch to work unless I commit (sorry, first time
using git :slight_smile: )

I am using boost 1.51 - I previously had an earlier version that I had
compiled, but at some point I downloaded the prebuilt binaries to try
and
fix an issue. It didn’t fix the issue, but now I have the latest version
of
boost :slight_smile:

As for the windows audio sources: yes, the windows audio source is
empty,
but the portaudio one is not. In order to get it to work I had to set
audio_module = portaudio in C:\Program Files
(x86)\gnuradio\etc\gnuradio\conf.d\gr-audio.conf. I think there might
also
be a way involving importing only the audio_portaudio module in Python,
but
I haven’t investigated this yet. You also have to make sure you get the
device name right, or it’ll do nothing. For a while I thought I should
be
setting the device name to portaudio to tell the factory to create a
portaudio source, but I was wrong - the documentation could be a little
clearer on this.

4

On 12/13/2012 08:17 AM, wakjah ’ wrote:

Actually, I’m not sure that it was strictly necessary to remove all of
those from the make list; I just removed what I thought was affecting it
(anything that referenced if_tun.h - even if it was within a #if/#endif)
and it seemed to work.

OK cool, thats what I thought. I think there was a patch merged for this
ifdef yesterday after you reported the bug.

With regards to posting patches… yes, I can, but I’m not sure how. I
understand that I need to use git format-patch, but do I have to commit
beforehand? I thought the idea was that I would create a patch and submit
it, and then someone would commit and merge the patch later on, but I can’t
see how to get format-patch to work unless I commit (sorry, first time
using git :slight_smile: )

just send the output of “git diff” :slight_smile:

be a way involving importing only the audio_portaudio module in Python, but
I haven’t investigated this yet. You also have to make sure you get the
device name right, or it’ll do nothing. For a while I thought I should be
setting the device name to portaudio to tell the factory to create a
portaudio source, but I was wrong - the documentation could be a little
clearer on this.

There is only one audio source/sink block. The underlying implementation
is chosen based on compilation support and preference setting. So
setting the conf file is probably the best way to do this.

-josh