I have been using volk in some of our internal components if the volk library is detected on the system. I know that GNUHawk packages a version of volk in the deps folder within SDRROOT. We just created a new Linux image with CentOS 6.6 and Redhawk 1.10.0-10 installed from the RPMs available online. Previously we had been building gnuhawk from source. When running our custom components we get symbol lookup errors due to the symbol table having been stripped from libvolk that is packaged with RPM version of gnuhawk.
What is a suggested way around this issue? Should we create another softpackage dependency with our own version of libvolk in it instead of using the gnuhawk libvolk?
You shouldn't have any issues using the volk shared objects packaged with gnuhawk but I'd have to get more info to know for sure what's going on. My guess is that you may be compiling against a system install of libvolk and then running against the gnuhawk version which could cause a symbol look-up issue.
Make sure you are compiling and linking against the volk files within the SDRROOT. You should be able to use the pc file ($SDRROOT/sdr/dom/deps/gnuhawk/lib/pkgconfig/volk.pc) to setup your CXX & LD Flags automatically with autotools
You can see the symbols within the libvolk object using readelf. Use readelf -s on the libvolk.so.0.0 shared object and it should print out the symbol table. You can then confirm the symbol in question is missing and start hunting for how you were linked against that symbol in the first place.
You can of course create your own shared object library with your volk headers & shared objects. This gives you the flexibility to update volk and breaks your dependence on gnuhawk.