Description of problem: Any executable that uses directly or indirectly libuhd fails to start. This is used by gnuradio as an interface to one particular software defined radio. However because of the way osmocom is packaged it also means that you can't use any radio supported by osmocom in gnuradio. Version-Release number of selected component (if applicable): boost-devel-1.60.0-5.fc24.x86_64 (& uhd-3.8.2-10.fc24.x86_64) How reproducible: 100% Steps to Reproduce: sudo dnf install uhd ldd -r /lib64/libuhd.so.003 | c++filt Actual results: ... undefined symbol: boost::re_detail_106000::cpp_regex_traits_implementation<char>::transform_primary(char const*, char const*) const (/lib64/libuhd.so.003) undefined symbol: boost::re_detail_106000::cpp_regex_traits_implementation<char>::transform(char const*, char const*) const (/lib64/libuhd.so.003) $ Expected results: ... $ Additional info: There is a chance that this is actually a build problem with the uhd package, but I think it's more likely an issue of symbols disappearing from libboost_regex between the version uhd was built with and the version currently in fedora 24.
I have a similar issue when I use launch the program gqrx /usr/bin/gqrx: symbol lookup error: /lib64/libuhd.so.003: undefined symbol: _ZNK5boost16re_detail_10600031cpp_regex_traits_implementationIcE17transform_primaryEPKcS4_
uhd needs to be rebuilt against the current Boost package, but the rebuild fail on ARM (see Bug 1331983 comment 27). Once uhd is rebuilt then gqrx needs to be rebuilt too. The ARM failure is Bug 1308204 and it looks like a new build is already available in the updates-testing repo, please test it and leave feedback if it works. *** This bug has been marked as a duplicate of bug 1308204 ***