Hey group,
As we discussed on our call last week, we are trying to move ahead to
getting GNU Radio 3.4 released. To do this, we have a big shift to
make, which is making our current ‘next’ branch into the ‘master’
branch and cutting a new ‘next’ from there. But before we do this,
Johnathan and I would really like to make sure that ‘next’ is ready to
become or main, master branch.
Mostly because of the introduction of UHD, we have seen more use of
the next branch than I think we would have otherwise. That makes me
feel more comfortable using it. However, we are concerned that we have
not stress-tested it enough. I know we recently found a problem in the
howto-write-a-block code (which actually still needs some cleanup,
thanks Mike C.), and so we would like to know if there are any further
problems with the branch.
I would ask all of you who can to start either using or at least
testing out the ‘next’ branch now and provide us with feedback and bug
reports.
I would ask all of you who can to start either using or at least
testing out the ‘next’ branch now and provide us with feedback and bug
reports.
Compilation on Cygwin fails because there is no <complex.h> (#included
by
volk_complex.h) in Cygwin. In fact, there appears to be no support in
the
Cygwin C library for complex types
(NOT implemented system interfaces from the Single Unix Specification, Volume 7:). (Complex numbers
are
supported in Cygwin’s g++, however.)
Unless there is some reasonable way to avoid requiring complex.h (or to
avoid building volk), we will need to abandon GNU Radio under Cygwin.
(That
wouldn’t bother me too much, as long as it works under
MinGW—especially if
support could be provided building with MSVC.)
Unless there is some reasonable way to avoid requiring complex.h (or to
avoid building volk), we will need to abandon GNU Radio under Cygwin. (That
wouldn’t bother me too much, as long as it works under MinGW—especially if
support could be provided building with MSVC.)
– Don W.
Thanks, Don. That’s really good to know and wouldn’t have even crossed
my mind (the more I have to interact with Cygwin, the less impressed I
get).
I would ask all of you who can to start either using or at least
testing out the ‘next’ branch now and provide us with feedback and bug
reports.
Two more issues with the ‘next’ branch:
(1) It appears that the Boost ‘system’ and ‘filesystem’ modules are now
required. This should be documented somewhere.
(2) The Boost ‘filesystem’ module does not build on MinGW, because
wstring
is not supported in its libstdc++. I will look at the latest MinGW to
see
if this has changed. One possibility is to use an alternate C++ library
(such as STLPort), but that sounds like a lot of work.
Unless there is some reasonable way to avoid requiring complex.h (or to
avoid building volk), we will need to abandon GNU Radio under Cygwin.
(That wouldn’t bother me too much, as long as it works under
MinGW—especially if support could be provided building with MSVC.)
(2) The Boost ‘filesystem’ module does not build on MinGW, because wstring
is not supported in its libstdc++. I will look at the latest MinGW to see
if this has changed. One possibility is to use an alternate C++ library
(such as STLPort), but that sounds like a lot of work.
Boost “filesystem” is available on Cygwin, also wstring support.
At least with my GCC 4.3.4 and my Boost 1.43.
I’m only missing the libboost_unit_test_framework.
An MSVC port is looking better all the time!
But isn’t this a huge effort, porting all to the Microsoft ecosystem?
Cygwin porting should be much easier now, since UHD does not
force raw ethernet access any more. Raw ethernet is totally
incompatible between Linux and Cygwin, because Cygwin is using
the Microsoft network drivers. Standard UDP/IP traffic can be
implemented in a compatible way between Cygwin and Linux.
Also libusb is available for both (libusb-win32 port).
I would ask all of you who can to start either using or at least
testing out the ‘next’ branch now and provide us with feedback and bug
reports.
I installed the Cygwin 1.43 boost libraries, but:
checking for exit in -lboost_unit_test_framework… no
Could not link against libboost_unit_test_framework!
Some time ago I had Gnuradio running on Cygwin with XWindows,
Waterfall diagram and soundcard interface. USRP support failed to build.
I had problems building certain packages, but those I found precompiled
on http://sourceware.org/cygwinports/
Compilation on Cygwin fails because there is no <complex.h> (#included by
volk_complex.h) in Cygwin. In fact, there appears to be no support in the
…
Unless there is some reasonable way to avoid requiring complex.h (or to
avoid building volk), we will need to abandon GNU Radio under Cygwin. (That
Why do you need C complex types?
The br_complex is based on C++ complex:
and volk complex too:
typedef std::complex lv_32fc_t;
typedef std::complex lv_64fc_t;
Most of the code is C++, only a few routines in C.
Is is worth maintaining different complex data types?
wouldn’t bother me too much, as long as it works under MinGW—especially if
support could be provided building with MSVC.)
Usually Cygwin is the direct way of porting Posix/Linux software to
Windows.
In most cases, “./configure ; make” will do the job.
MinGW is less Posix compatible. And MSVC is not compatible at all.
The dual Posix/MSVC projects I checked out had very ugly code with lots
of
preprocessor switches for all the Windows special treatments.
I think the Posix/Linux way is still recommended for Gnuradio,
especially for the new devices with an embedded PC component.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
