gnuradio: radio-companion: app opens, but sometimes crashes... or does not update upon variable changes

[vjarao]

Good morning ... I had successfully installed gnu radio on Mac M1 running Monterrey 12.4. The application (gnu radio-companion) opens without errors. Furthermore, if running a static xxx.grc all works. However, if I ran a flow graph with QT Range, for sweeping variable values, it does not updates and often crash the application.

Could you please ran the attached file and let me know if in your installation runs?

[michaelld (Michael Dickens)]

Very interesting! I run this on my Mac Intel laptop (macOS 11; GR 3.8 "gnuradio" port) and it works fine. I run it on my Mac Mini M1 (macOS 11; GR 3.10 "gnuradio-next" port) & it works as noted: static, not dynamic! Let me upgrade "gnuradio-next" to the current 3.10 release & then try same-version on both computers. I'm guessing this is a Qt5 issue, rather than a GNU Radio issue ... but, who knows? Thanks for reporting!

[vjarao]

Good evening. I believe your early diagnostic is correct. I just ran port update and upgrade outdated and received the following error message:

---> Fetching archive for py39-pyqt5 ---> Attempting to fetch py39-pyqt5-5.15.7_0.darwin_21.arm64.tbz2 from ​https://packages.macports.org/py39-pyqt5 ---> Attempting to fetch py39-pyqt5-5.15.7_0.darwin_21.arm64.tbz2 from ​https://ywg.ca.packages.macports.org/mirror/macports/packages/py39-pyqt5 ---> Attempting to fetch py39-pyqt5-5.15.7_0.darwin_21.arm64.tbz2 from ​https://mse.uk.packages.macports.org/py39-pyqt5 ---> Building py39-pyqt5 Error: Failed to build py39-pyqt5: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyqt5/py39-pyqt5/main.log for details. Error: Follow ​https://guide.macports.org/#project.tickets if you believe there is a bug.

The main.log is attached main.log

[michaelld (Michael Dickens)]

@vjarao: In order to get py*-pyqt5 to build on my systems, I have to add in use_xcode yes to the Portfile ... I do it right after compiler.cxx_standard 2011. Strongly believe this will do the trick for your install too.

[vjarao]

Thank you vow the hint. I ran "sudo port -v upgrade outdated use_xcode yes" and now the error is different (about the SDK). It seems to me there is progress ...

: :

/opt/local/libexec/qt5/bin/qmake -recursive PyQt5.pro sip-build-3.9: '/opt/local/libexec/qt5/bin/qmake -recursive PyQt5.pro' failed returning 3 Project ERROR: Could not resolve SDK Path for 'macosx12' using --show-sdk-path Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyqt5/py39-pyqt5/work/PyQt5-5.15.7" && sip-build-3.9 --qmake /opt/local/libexec/qt5/bin/qmake --verbose --confirm-license --dbus=/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9/dbus-1.0 --disable QtWebKit --disable QtWebKitWidgets Exit code: 1 Error: Failed to build py39-pyqt5: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.or

[michaelld (Michael Dickens)]

I don't think you can set that variable via the commandline. I think it has to be inside the Portfile itself. The error you note (Could not resolve SDK Path for 'macosx12' using --show-sdk-path) is a symptom of that variable not being set, by the way. You can edit the Portfile via sudo vi $(port dir py39-pyqt5)/Portfile and make the change manually. Once you redo the install, and assuming this works, then remember to revert the change for future updates to that Portfile.

[vjarao]

Progress ... I was able to go through an entire cycle of update and upgrade outdated. There were 2 issues in my installation. 1) Somehow Xcode command line tool weren't properly installed. I fixed that, and 2) following your advice of using "use_xcode yes", now qt5 updates and installs.

I ran 3 times sudo port -v self update and sudo port upgrade outdated cycles, rebooting on every iteration. Each time NO error at all.

Unfortunately, the original problem persists. This is gnuradio works on static, not dynamic. I even connected a SDR to remove the throttle block and same static behavior was observed.