OSX Soapy Paths problem

[mpvano]

Hi: Thanks for all the great work, especially for the latest 2.7.1 binary for OSX. It works nicely on my 2015 MBPro with my rtlsdr device.

Now that you've updated to a current Soapy, I was hoping to also use it with my SDRPlay rsp2, but I have run into a problem using gqrx with Soapy devices.

The search path for Soapy devices that you have built in doesn't work with my devices (which were installed using the popular brew package manager). In fact, if the SoapySDRUtility you shipped in the bundle is to be trusted, your soapy search path is pointing to somewhere in your home directory.

$ ./SoapySDRUtil --info
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.6.1-g285e72aa
API Version: v0.6.0
ABI Version: v0.6
Install root: /Users/alc/gqrx/runtime
Search path: /Users/alc/gqrx/runtime/lib/SoapySDR/modules0.6
No modules found!
Loading modules... done
Available factories...null,

It's not an end user feature to preset environment variables on the Macintosh for GUI programs, but I've confirmed that this is the problem by running gqrx from a small script file named "Gqrx.command" on my desktop that configures an environment variable properly for the search. Gqrx works properly when run this way.

#!/bin/sh
cd /Applications/Gqrx.app/Contents/MacOS/
export SOAPY_SDR_ROOT=/usr/local
./gqrx

I don't know what's a good solution to this is, since there are several different ways to do unix installs on MacOS. The fix above works for MY Soapy installation, which was done from the "brew" package manager, but I believe other prefixes might be needed by other users.

There may be a workaround by patching the .plist in your bundle.

Thanks for reading this...

Mario Vano

[csete]

Thanks for the info.

I guess users can have soapy modules installed in arbitrary location, although having /usr/local as default search path seems like a good idea. I know very little about what's going on on Mac OS X so any suggestion how I can set it in plist is welcome.

[mpvano]

This is purely speculation on my part, but it might help:

People can override installation options with any package manager, but they all have default places they install things. As far as I know, the only package managers currently popular are Fink, Homebrew and MacPorts - it's been years since I've used anything but Homebrew however.

Homebrew simply uses /etc/local for an installation prefix
MacPorts uses /opt/local
Fink uses /sw

However, I have no idea where MacPorts and Fink actually install SoapySDR.

One could argue that since /etc/local is a relatively standard place to put such things in Unix people can always add links between their /sw or /op based installations and corresponding directories in /etc/local.

I tried adding a colon separated list of prefixes to the text of the environment variable, but that did not seem to work.

Naturally, Homebrew users like me would be perfectly pleased if you used "/usr/local"!

In any case, here's the trivial edit to your plist file that seems to work here:

Info.plist.zip

MacOS (at least Sierra) seems to cache plist files for apps, so editing it in place seems to have little effect as a quick fix. Perhaps this is done for security reasons. I found that I needed to edit the plist, then drag the app to the trash. When "put back" from the trash the new environment was in effect.

Having the finder restore an app from the trash seems to rename the app with a unique timestap added. I had to manually rename it back to "gqrx".

hope this all helps - at least as a temporary workaround.

[csete]

I have just uploaded the v2.9 bundle where the proposed changes to the Info.plist are included.

We can leave this issue open for a while to see if there is any more feedback or other ideas.

[mpvano]

The 2.9 version with the bundle change looks good here. It immediately found my SoapySDR driver and used it.

I haven't had much time to test it otherwise...

Thanks....