Installing REDHAWK on Fedora 24

At GRCon16 last month, there were a number of discussions about deploying GNU Radio applications to REDHAWK networks. REDHAWK has a lot of very compelling features, especially in the management & provisioning of network-attached SDR resources, application management, and data stream control.

[I actually worked on the predecessor to REDHAWK, the OSSIE project, while I was an undergrad at VT, so I have some knowledge about the general system design. REDHAWK has changed a lot since it's original fork from OSSIE, though, so my practical knowledge of it is very limited.]

The easy way to get REDHAWK up and running is by using the Docker containers provided by Geon Technologies. This is almost certainly the best way to get rolling on modern OSes as the only available installers are for CentOS 6.

Mostly because I'm curious, I decided to try and build REDHAWK natively on my Fedora 24 system. I'm honestly not sure how successful I was, as I haven't gotten a chance to really use or test it thoroughly. I did get far enough that most of the core framework unit tests were passing, though.

Anyway, these were my steps:

Installing REDHAWK

The Installation Instructions provided by the project are extremely helpful, but you'll need to deviate a bit to get it running on an OS as recent as Fedora 24.


First, the easy ones. Grab these from the official F24 repos:

$ sudo dnf install omniORB-servers omniORB-devel python-jinja2 xsd libtool apr-devel apr-util-devel libuuid-devel boost-devel autoconf automake libtool expat-devel java-1.8.0-openjdk-devel python-devel numpy PyQt4 omniORBpy-libs libuuid-devel


Next, we need log4cxx. Unfortunately, there is no official package for log4cxx after Fedora 23, so we have to build this one from source. To make things more complicated, log4cxx hasn't been updated to be compatible with GCC6, which is the default system compiler used by F24. So, we'll need to patch the source.

Thankfully, there is an Archlinux AUR package for log4cxx that includes the patches needed to make log4cxx build with GCC6. Note that you'll need to use the tarball of the source included with the PKGBUILD, as opposed to just grabbing the patches and the latest checkout of log4cxx, because the latest SVN has deviated from the PKGBUILD.

Grab the PKGBUILD sources and apply the patches to the source:

$ tar xzvf apache-log4cxx-0.10.0
$ cd apache-log4cxx-0.10.0
$ patch -p1 < ../log4cxx/log4cxx-0.10.0-missing_includes.patch
$ patch -p1 < ../log4cxx/log4cxx-0.10.0-narrowing-fixes-from-upstream.patch

Next, let's build it. I recommend installing it to a user prefix, which you can see I've done below.

$ ./configure --prefix=/home/bhilburn/usr --disable-static
$ make -j4
$ make install

Unfortunately, make check yields one failure (out of two tests) for me. I didn't look into how to fix these. Hopefully they aren't serious?

Building REDHAWK

Okay, ignoring any broken dependency installs that may or may not be indicated by that failed log4cxx test, let's blaze ahead to actually build REDHAWK.

First, grab the source:

$ git clone --recursive redhawk.git

You'll need to make some changes to the code in order for it to build, all of which are in the core-framework. I pushed a branch with the four required changes, which you can find here. I also filed a pull request against the upstream repository, so this step may not be necessary eventually.

Here is the patch, created with git diff, that should cleanly apply:

diff --git a/src/control/framework/nodebooter.cpp b/src/control/framework/nodebooter.cpp
index d79c291..dbd97ad 100644
--- a/src/control/framework/nodebooter.cpp
+++ b/src/control/framework/nodebooter.cpp
@@ -141,7 +141,7 @@ void loadPRFExecParams (const std::string& prfFile, ExecParams& execParams)
     } catch (const ossie::parser_error& ex) {
         std::string parser_error_line = ossie::retrieveParserErrorLineNumber(ex.what());
-        LOG_ERROR(nodebooter, "Failed to parse PRF file " << prfStream<< ". " << parser_error_line << "The XML parser returned the following error: " << ex.what());
+        LOG_ERROR(nodebooter, "Failed to parse PRF file " << prfFile<< ". " << parser_error_line << "The XML parser returned the following error: " << ex.what());
diff --git a/src/control/sdr/dommgr/ApplicationFactory_impl.cpp b/src/control/sdr/dommgr/ApplicationFactory_impl.cpp
index d370519..92699e0 100644
--- a/src/control/sdr/dommgr/ApplicationFactory_impl.cpp
+++ b/src/control/sdr/dommgr/ApplicationFactory_impl.cpp
@@ -194,7 +194,7 @@ void ApplicationFactory_impl::ValidateSPD(CF::FileManager_ptr fileMgr,
                                           const bool require_prf, 
                                           const bool require_scd) {
   SoftPkg pkg;
-  ValidateSPD(fileMgr, pkg, false, false );
+  ValidateSPD(fileMgr, pkg, sfw_profile, require_prf, require_scd);

 void ApplicationFactory_impl::ValidateSPD(CF::FileManager_ptr fileMgr, 
diff --git a/src/control/sdr/dommgr/applicationSupport.cpp b/src/control/sdr/dommgr/applicationSupport.cpp
index 1daa7ce..fbb5ac8 100644
--- a/src/control/sdr/dommgr/applicationSupport.cpp
+++ b/src/control/sdr/dommgr/applicationSupport.cpp
@@ -853,7 +853,7 @@ const bool  ComponentInfo::isScaCompliant()

 bool ComponentInfo::isAssignedToDevice() const
-    return assignedDevice;
+  return static_cast<bool>(assignedDevice);

 bool ComponentInfo::checkStruct(CF::Properties &props)
diff --git a/src/testing/sdr/dev/devices/CppTestDevice/cpp/CppTestDevice.h b/src/testing/sdr/dev/devices/CppTestDevice/cpp/CppTestDevice.h
index 8e1c396..af71c53 100644
--- a/src/testing/sdr/dev/devices/CppTestDevice/cpp/CppTestDevice.h
+++ b/src/testing/sdr/dev/devices/CppTestDevice/cpp/CppTestDevice.h
@@ -28,7 +28,7 @@ class CppTestDevice_i : public CppTestDevice_base
-       static const float MAX_LOAD = 4.0;
+       static constexpr float MAX_LOAD = 4.0;

        CppTestDevice_i(char *devMgr_ior, char *id, char *lbl, char *sftwrPrfl);
         CppTestDevice_i(char *devMgr_ior, char *id, char *lbl, char *sftwrPrfl, char *compDev);

With the patch applied, let's build:

# The below step is only necessary if you installed to a user prefix
$ export PKG_CONFIG_PATH=/home/bhilburn/usr/lib/pkgconfig:$PKG_CONFIG_PATH
$ cd src/redhawk.git/redhawk/core/src
$ ./reconf
$ ./configure --prefix=/home/bhilburn/usr
$ make -j<something>

In order to run make test, we need to actually have the OmniORB nameserver running. First, configure the nameservice by adding this line to /etc/omniORB.cfg:

InitRef = EventService=corbaloc::

Then start the service itself:

sudo systemctl start omniNames.service

If the above doesn't successfully start the service, you can give the below a shot to see what the output is:

$ /usr/bin/omniNames -start -always -logdir /var/log/omniORB/ -errlog /var/log/omniORB/error.log

Once omniNames is running, you should be able to actually run make test in your REDHAWK build directory. With these steps, the tests take about 30 minutes and I get 11 failures out of 498 tests.

Ran 498 tests in 1587.850s
FAILED (failures=11, errors=35)

Hopefully this is useful to someone. Happy hacking!

Ben Hilburn

Ben Hilburn

bits, nibbles, bytes, and words
D.C. Metro Area