Using latest gr-osmosdr with gr-iqbal (FYI)

[markjfine]

This is likely a problem with gnuradio and NOT gqrx, but it does impact gqrx operation when IQ Balance is selected. Wanted to put a marker in here as an FYI to head off any future issues that may be reported for gqrx.

Rebuilt gr-osmosdr at the weekend (while investigating #1414), and happened to notice that it wasn't including gr-iqbal. gr-osmodsr was looking for it where gnuradio is installed. I use Homebrew for gnuradio, but it doesn't similarly provide bottles for gr-iqbal (nor libosmo-dsp). Those two need to be built from scratch, so I modified gr-osmosdr to ensure gr-iqbal (and prerequisite libosmo-dsp) was seen. I then rebuilt gqrx to reflect the change to gr-osmosdr. Shortly afterwards, I started noticing gqrx's display badly glitching after a while if the IQ Balance input control was selected, requiring a restart of gqrx. For clarity, the glitch ultimately appears as if the receiver was disconnected.

gr-iqbal hasn't really been maintained (other than @argilo's update of the libosmo-dsp url) since 2021, where it was updated for compatibility with gnuradio 3.9. gnuradio is currently at 3.10 (per Homebrew) and has been since 2022.

So, a word of caution for anyone that dares to tread: Any gr-osmosdr builds using gnuradio 3.10 is best left without gr-iqbal until the maintainer (@smunaut) updates it over at osmocom.org. if it's even really needed.

[smunaut]

I build gr-iqbal with gnuradio git 3.11 just fine ...
There wasn't any update to it because none are needed, it just works.

[markjfine]

There wasn't any update to it because none are needed, it just works.

@smunaut

It works for you, but as I explained:

1. There is the issue of building against Homebrew gnuradio, so ${Gnuradio_DIR} points to /opt/homebrew/lib/cmake/gnuradio in gr-osmosdr's CMakeLists.txt. gr-iqbal is built locally so its cmake is at /usr/local/lib/cmake/gnuradio.
2. Not using gnuradio git 3.11. Using 3.10.12 as released via Homebrew on 19 Feb.

This configuration is not working despite fully investigating and pinpointing the problem.

If I may: There's no way to even post an issue for anything related to osmocom-mirrored repositories on github, nor on the osmocom site. So consider this an unofficial issue report (your first?).

[argilo]

Gqrx's DMG releases build gr-iqbal and gr-osmosdr against GNU Radio from Homebrew, and no modifications are required:

gqrx/.github/workflows/build.yml

Lines 135 to 152 in 78d0814

	cd /tmp
	git clone https://gitea.osmocom.org/sdr/gr-iqbal.git
	cd gr-iqbal
	git submodule update --init --recursive
	mkdir build
	cd build
	cmake -DCMAKE_BUILD_TYPE=Release ..
	make -j4
	sudo make install
	cd /tmp
	git clone https://gitea.osmocom.org/sdr/gr-osmosdr.git
	cd gr-osmosdr
	mkdir build
	cd build
	cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=-Wno-register ..
	LIBRARY_PATH=/usr/local/opt/icu4c/lib make -j4
	sudo make install

Perhaps there is something different in your setup.

[markjfine]

@argilo

They'll both build just fine. However, if you check the cmake output from gr-osmosdr it may say that it couldn't find gr-iqbal's cmake with the other gnuradio cmake files.

-- Configuring Osmocom IQ Imbalance Correction support...
--   Dependency gnuradio-iqbalance_FOUND = 0
--   Disabling Osmocom IQ Imbalance Correction support.
--   Override with -DENABLE_IQBALANCE=ON/OFF

It then ignores it.

-- ######################################################
-- # Gnuradio disabled components                        
-- ######################################################
--   * Osmocom IQ Imbalance Correction

You can get it to see it by changing line 148 in gr-osmosdr CMakeLists.txt from

find_package(gnuradio-iqbalance PATHS ${Gnuradio_DIR})

to wherever gr-iqbal puts it's cmake, such as

find_package(gnuradio-iqbalance PATHS /usr/local/lib/cmake/gnuradio)

and it will build with it. But by doing so, gr-iqbal doesn't behave correctly.

There may in fact be other things that need to be done to make this work correctly using this kind of configuration, both in gr-osmosdr, as well as gr-iqbal. The fact that gr-osmosdr is using the cmake to determine it's existence and not detecting where it's actually installed (e.g., via pkgconfig) may be part of the problem.

[argilo]

I see now that gr-iqbal is enabled in the x86_64 build but disabled in the arm64 build:

https://github.com/gqrx-sdr/gqrx/actions/runs/14041381699/job/39312142921#step:3:1406

https://github.com/gqrx-sdr/gqrx/actions/runs/14041381699/job/39312142942#step:3:1430

So it does appear there is an issue, I just hadn't noticed because I don't have an ARM-based Mac.

[markjfine]

No problem. I got your back...

It also doesn't help that Homebrew moved everything for ARM installations from /usr to /opt. I suppose that's to avoid x86 conflicts, but still.

[argilo]

In CI for other projects, I've dealt with that by using $(brew --prefix) where needed. It probably isn't a good idea to assume a fixed Homebrew prefix in any case.

[markjfine]

Bottom line, I still maintain that needs to be addressed by gr-osmosdr and gr-iqbal maintainers.
Apologise for posting it here, but there is just no other place to put it that ensures gqrx users know that it's not a gqrx issue.

[argilo]

Yeah, I suppose a possible fix would be for gr-osmosdr to search for gr-iqbal both in the GNU Radio directory and the default search path.

Alternatively, Gqrx could install gr-iqbal and gr-osmosdr to the GNU Radio directory. I'm not sure whether it's OK to install non-Homebrew stuff into the Homebrew prefix.

[smunaut]

Or package both in HomeBrew in the first place ...

[markjfine]

All very good ideas.

Edit: However, as this particular issue was discovered while investigating a Homebrew bottle error that hasn't been fixed since it was identified on 6 Mar (fftw built with no SDK version, gqrx issue #1414), we could be inviting additional problems by fully going the Homebrew route.

I'd raise the idea of taking building gnuradio locally instead of letting Homebrew provide updates, but that almost seems like an unnecessary system maintenance headache.

[argilo]

Agreed that using Homebrew packages in Gqrx releases is problematic. For one thing, Homebrew packages have their deployment target set to the macOS version of the build machine (currently 13 for x86_64, and 14 for arm64), and will not run on older versions of macOS.

Building all dependencies from source would be possible, but it would be painful to maintain. It would be great if we could use Conda packages. There are Conda packages for all of Gqrx's dependencies, and we already use them to build AppImage binaries for Linux.