Problem compiling gr-sdrplay3 on Mac
fventuri opened this issue · 10 comments
@bob-uk reported the following problem:
On the issue of the gr-sdrplay OOT modules, I hadn't clocked their import so am looking at them now. As I said I have gr 3.8 loaded and running so have built 3.9 and installed it to a diffefent location, hopefully they won't trample on each other. I am running on mac Catalina and have some problems compiling gr-sdrplay3, both with clang and gcc/g++
in rsp_impl.h this construct fails "const double (&get_freq_range() const override)[2];" with a compiler error requesting a ')' before the override?
and then it is failing deep in the Xcode includes
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:1547:38: error:
implicit instantiation of undefined template
'std::__1::hash<sdrplay_api_ReasonForUpdateT>'
: public integral_constant<bool, __is_empty(_Tp)> {};
so a bit stuck on this route at present
Bob
Bob,
I am running Linux here (Fedora 33, to be exact) so there are probably a few differences between Linux and Mac that we just need to figure out.
A few notes:
- to make sure we are both on the same page (and that the code in the repo compiles with the current headers of GNU Radio from master), I made a clone of this repository in a new directory, compiled with gcc, and it compiled everything without errors or warnings
- my compiler here is:
g++ --version g++ (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6) Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - as per that very cryptic error message, I think the problem is line 848 in file 'rsp_impl.cc':
static const std::unordered_map<sdrplay_api_ReasonForUpdateT, const std::string> reasons = { - the explanation (see here: https://stackoverflow.com/questions/18837857/cant-use-enum-class-as-unordered-map-key) seems to be that some compilers (or compiler versions) do not like an unordered_map (aka a hash) that uses an enumeration as the key, and require the code to have some sort of hashing function
- if my understanding is correct, that issue comes perhaps from the compiler version (and/or the compilation flags) that you are using; do you mind sending me the output of 'g++ -version', and attaching the output from 'make VERBOSE=1'?
Thanks,
Franco
Franco
Thank you again for the prompt response and help. Just to update you on where I have got too.
I have been doing some more investigation and it looks like I have been using Apple clang all along. I though /usr/bin/g++ was the gnu version but it is really clang. I have now tried to build using a real gnu compiler in /usr/local/bin.
So to be clear the compile problem I was having was coming from clang
So this is the clang version
c++ --version
Apple clang version 12.0.0 (clang-1200.0.32.27)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
and this is the gcc compiler version
/usr/local/bin/g++-10 --version
g++-10 (Homebrew GCC 10.2.0) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
When I use the gnu g++ I now have a different problem which is totally mac related in that the linker is throwing "ld: symbol(s) not found for architecture x86_64" I need to track this down and I will get back to you on this one. Looks like it might be a boost library mismatch. So it is compiling but not linking with gnu g++.
Separately my setup is a headless Pi4 running the rsp image with extras connected to the duo (Dedian Buster). I run this both through SoapyRemote and locally in a vnc session to try and detemine where issues lie. I will build GR 3.9 later today on the Pi, but as you appreciate it takes a while.
Bob
Franco
Further update, gr 3.9 has the same library problem when linking with the gnu compiler, so will look into this further. This appears to be a particularly mac osx problem
Bob
Bob,
thanks for pointing out to the problems compiling the code under clang/clang++.
I just pushed a commit with a few code changes (mostly with missing 'override' in several places; looks like gcc/g++ is more lenient than clang about that) to the repository; the module now compiles cleanly here (no errors or warnings) with both gcc/g++ and clang/clang++.
The command I used here on Linux to create a clang build is:
CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake ..
(all the other commands are the same)
Give it a try when you have time, and let me know if it works on your Mac too.
Franco
Franco
Thanks for the update, which has fixed the compile issues with override, unfortunately still failing in the Xcode include files, process outlined below with hopefully helpful files.
I have done a pull from the repository, cleaned out build directory, invoked cmake with
cmake -DCMAKE_INSTALL_PREFIX=~/prefix-3.9 -Wno-dev ..
make VERBOSE=1, output attached and it is failing with the attached - problem with the Mac include files I think
Output from c++ --version
c++ --version
Apple clang version 12.0.0 (clang-1200.0.32.27)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Will continue working on the library problem with gnu g++ in the meantime
Bob,
I just added a hash function to the declaration of those 'unordered_map' data structures, as suggested here: https://stackoverflow.com/a/22361511
When you have time, pull the repo again, try to build it using clang, and hopefully this time you'll be able to compile on your Mac without any error or warning.
Franco
Franco
Just a quick update. I have pulled the repo and it now compiles, but linker complains of undefined sysmbols. Looking on the web it appears that on the mac "-undefined dynamic_lookup" needs to be defined to the linker - this appears to be the default for g++ on linux. Added this to CMakeCache.txt and it builds, so now looking to do some testing tomorrow
Thanks for the support.
I will update you when I have a built and tested flow graph
Bob
Thanks Bob for the update.
Once you get everything working there, please let me know what you did to get it to work on your Mac, so I can add a section for Mac users in the README (I believe you are the first one to try to compile it and run it on a Mac).
Franco
Franco
Just a quick interim update. Still working through Mac dependancy hell! Unlike linux distributions which have a unified package manager for a given distribution, no such animal exists in the Mac OSX space. Apple doesn't provide a package manager so a number have emerged, with two main ones being macports and homebrew - unfortunately they don't play nicely with each other and like most developers, I suspect, I have used both and should have known better:( So now in the process of working through the various problems and for those Mac developers out there have opted to major on macports.
On a separate note I managed to get a GR 3.9 flowgraph using sdrplay3 to successfully run on my target pi4. Haven't managed to get any further with that due to the above.
Will update when I come out the other side
Bob
Thanks for the update Bob.
I am glad to hear that gr-sdrplay3 is working on your Raspberry Pi.
I am just curious: what do those Mac errors say?
Franco