Mac OS clang 12: fails to detect native device extensions

[cpatulea]

Expected Behavior

$ ./setup.py install
$ urh

Actual Behavior

$ ./setup.py install
$ urh
<urh shows no native device extensions, only gnu radio backend>

Steps To Reproduce

1. Use Mac OS clang 12:
   cc -v
   Apple clang version 12.0.0 (clang-1200.0.32.2)
   Target: x86_64-apple-darwin19.6.0
   Thread model: posix
   InstalledDir: /Library/Developer/CommandLineTools/usr/bin
2. Run urh.dev.native.ExtensionHelper:
   $ PYTHONPATH="/usr/local/Cellar/urh/2.8.9_2/libexec/lib/python3.9/site-packages:/usr/local/opt/cython/libexec/lib/python3.9/site-packages:/usr/local/Cellar/urh/2.8.9_2/libexec/vendor/lib/python3.9/site-packages" /usr/local/Cellar/python@3.9/3.9.0_1/bin/python3 -m urh.dev.native.ExtensionHelper -v -v
   Skipping native support for airspy
   Skipping native support for bladerf
   Skipping native support for hackrf <-- !!
   Skipping native support for limesdr
   Skipping native support for plutosdr
   Skipping native support for rtlsdr
   Skipping native support for usrp
   Skipping native support for sdrplay

Screenshots

Platform Specifications

• OS: Mac OS 10.15.7 Catalina
• URH version: 2.8.9
• Python version: 3.9
• Installed via Homebrew

--

Above is purely what I'm trying to do, below is what I believe to be the problem:

ExtensionHelper compiler_has_function tests for native device library like this:
f = open(file_name, 'w')
f.write('int main(void) {\n')
f.write(' %s();\n' % function_name)
f.write('}\n')
f.close()

except this appears to have become an error in Clang 12:
$ cat test.c
int main(void) {
hackrf_init();
}
$ cc -o test test.c -lhackrf
test.c:2:3: error: implicit declaration of function 'hackrf_init' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
hackrf_init();
^
1 error generated.

So ExtensionHelper thinks the library is absent, when in reality the error is unrelated.

Just by declaring the function, this can work:
$ cat test.c
void hackrf_init();
int main(void) {
hackrf_init();
}
$ cc -o test test.c -lhackrf

So I think ExtensionHelper should be modified to declare the function before trying to call it.

[jopohl]

Any reason you build it yourself instead of using the provided DMG?

Moreover, for situations like this there is a flag, so you can just run python setup.py --with-hackrf to enforce building with HackRF extensions. See here.

[cpatulea]

reason you build it yourself instead of using the provided DMG?

I have ~200 packages installed by Homebrew, generally use it for third-party packages when possible. It is easier to manage install/uninstall/update, than manual installs of DMG for each.

From your perspective it is "build it myself" but in reality I just type "brew install urh".

python setup.py --with-hackrf

Yes, I understand it is possible to force the device extension. Even so, I think it would be worth improving the autodetection, so that it works under Clang 12.

(BTW it is difficult to pass '--with-hackrf' under Homebrew, so effectively any Homebrew user really relies on the autodetection to work correctly. But I understand this is not your fault.)

[cpatulea]

(Just as a data point, in terms of usage statistics from Homebrew, you have ~77 installs per month: https://formulae.brew.sh/formula/urh )

[jopohl]

Yes I understand your use case. I only have gcc under Linux for testing, so could you check whether it works with clang 12 when you add # include<hackrf.h> to the top of the check file? So it should look like:

$ cat test.c                                             
#include<hackrf.h>
int main(void) {
hackrf_init();
}

[cpatulea]

with default include paths, no:

/tmp$ cat >test.c
#include<hackrf.h>
int main(void) {
hackrf_init();
}
/tmp$ cc -o test test.c -lhackrf
test.c:1:9: fatal error: 'hackrf.h' file not found
#include<hackrf.h>
        ^~~~~~~~~~
1 error generated.

with include path to the homebrew install, yes:

/tmp$ cc -o test test.c -lhackrf -I/usr/local/Cellar/hackrf/2018.01.1/include/libhackrf
/tmp$

[cpatulea]

(btw, I followed your suggestion and downloaded the dmg, installed into /Applications, and the native backends do work:
airspy -- OK
bladerf -- OK
hackrf -- OK
limesdr -- OK
plutosdr -- OK
rtlsdr -- OK
sdrplay -- OK
usrp -- OK
SoundCard -- OK

[INFO] Used shared libraries from /Applications/urh.app/Contents/MacOS

Thank you for that workaround.

[jopohl]

You are welcome, I am glad you have a working version now.

Regarding the homebrew install I will think about this. It is a valid concern, that you need to specify the location of the header directory if it is not in the default search path. Declaring the hackrf_init() function in the file itself seems like the most end user friendly option indeed.

[Source975]

（顺便说一句，我按照你的建议下载了dmg，安装到/Applications中，原生后端可以工作： airspy -- OK bladerf -- OK hackrf -- OK limesdr -- OK plutosdr -- OK rtlsdr -- OK sdrplay -- OK usrp -- OK SoundCard -- OK

[信息]使用了 /Applications/urh.app/Contents/MacOS 中的共享库

感谢您提供该解决方法。
I would like to ask how to solve it if it is in window environment