Looking through the gr-osmosdr source code, there is no c++ standard set so CMake will default to something like c++98; not c++11 or later.
Looking through the libfreesrp code, it requires C++11 for building. It's public API also requires C++11, so to get gr-osmosdr support for freesrp you have to tell CMake to set the standard to C++11 when building at least the freesrp portions of gr-osmosdr; possibly the whole shebang since it's generally not wise mixing c++ runtime libraries. Given the above, I'd guess you're not alone or unique in this specific build, since this is the way the code is currently written. I haven't tried any of the above on Mac OS X / macOS, as libfreesrp doesn't play nicely with this OS yet & will take too much work for me to get going given my limited availability. Hope this helps! - MLD On Tue, Jun 20, 2017, at 12:25 PM, Ghost Op wrote: > I've run into this on every Ubuntu 16.04 box I've installed gnuradio > and OOT modules on and Google doesn't seem to have a nice clean answer > (the search answer is always add a compile flag) so I figured I'd ask > the group. > > When I build modules (gr-osmosdr in particular with libfreesrp support > I run into this) on a fresh Ubuntu 16.04.2 LTS install, I run into a > warning like this: "warning: non-static data member initializers only > available with -std=c++11 or -std=gnu++11". Depending on the code it > may produce errors on some lines preventing compilation. > > I know what causes it, the compiler is defaulting to something earlier > than the c++11 standard (like C++99) with the Ubuntu repo gcc version > (5.4) installed, so some of the syntax in the code is causing the > warning. I can modify the CMake and add this to it "set > (CMAKE_CXX_STANDARD 11)" and it builds after that, but my guess is > that this builds on everyone else's Ubuntu without these modifications > or the setting would be standard in the CMake files. What I'd really > like to do is tell the compiler to default to -std=C++11 even if it's > not explicitly provided as a compile flag, but again if everyone were > running into it I think it would have been fixed another way. > > If I do the same build on a standard debian build with gcc 6.3 it > builds clean so it's definitely a default standard issue for compilers > on Ubuntu 16.04. > > Does anyone have any insight/suggestions? _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio