ConfigGuide
SoapySDR has become very integral for a variety of SDR projects, and so newbies and experts alike may eventually find themselves installing SoapySDR, installing hardware support modules, compiling/developing applications against SoapySDR development files.
The platform has a variety of hardware support modules, languages options, packaging options, and client applications. And aside from being basically like any other library in the open source ecosystem, SoapySDR's hardware support modules, and architectural position as an abstraction layer tend to cause additional confusion, particularly when it comes to installing software.
The following guide is a list of common issues that come up on the github issues tracker, myriadrf formus, pothos users group, etc...
Table of contents
SoapySDR positions itself as an abstraction layer between applications and hardware drivers. This plays out in how SoapySDR relates with SDR applications and hardware support projects. So for example:
- Graphical applications like CubicSDR link against SoapySDR development files
- Python applications like QSpectrumAnalyzer import the SoapySDR python module
- Still other applications may use SoapySDR indirectly through an existing abstraction layer
- GQRX supports SoapySDR indirectly through gr-osmosdr and SoapyUHD projects
- Specific hardware support modules come from 3rd party projects that must be installed separately
- Many project compile against an existing C library, ex: SoapyRTLSDR requires librtlsdr
- Other projects bundle SoapySDR support along with the driver: LimeSuite provides SoapyLMS support
To give some idea how how these various software layers interact, here is a graphical (though not complete) topology of various SDR software drivers and applications, with SoapySDR in the middle acting as a bridge:
Note This is general advice geared to newbies coming across this software. Theres plenty of ways that this section could be more nuanced at the expense of becoming more confusing. So if you happen to know what you're doing, more power to you!
Packages manage the installation, lifetime, removal, and dependencies of a software project. We recommend using package installs whenever possible, unless you absolutely need the latest and greatest development HEAD of a particular project.
There are packages for many (though not all) of the common operating system choices out there. Here is a list of some of the supported packages: https://github.com/pothosware/PothosCore/wiki/Downloads
- For ubuntu and debian there are official deb packages for many of the SoapySDR projects
- In addition we maintain PPAs to provide packages for recent ubuntu releases
- For windows we have a all in one installer called PothosSDR
- We maintain a homebrew tap for OSX, although I hear MacPorts is good too
Source installs are not as streamlined as as a package management system and can get messy for beginners. There are development tools, development packages, compatible versions, configuration options, environment variables to deal with; and keeping track of whats installed from existing packages and whats in your installation directory (typically /usr/local).
Before we continue, ask yourself: "Why am I building this package from source?"
- Is it because its missing from the package management?
- Or is the version from the package management out of date?
- Otherwise, you are better off installing from the package
Note about dependencies
"What if I am building package X from source, do I need to build all of its dependencies from source?" No of course not. Going back to the previous rule, if those dependencies are available in the package manager and up to date, use them.
For example, someone wants to install the latest LimeSuite. In this case, they will probably want to clone and build LimeSuite from source. However, they may be tempted to also build SoapySDR from source. Which is technically an OK thing to do, however if you happen to be a newbie, then the extra complexity is probably not worth it.
Attention debian/ubuntu/PPA users
Unlike redhat style RPM packages and other, debian packages tend to put the development files into their own distinct package. If you need to develop against libfoo headers and libraries, you need to install the libfoo-dev package. So if the software you are building depends on SoapySDR for C/C++ compiling, please run:
sudo apt-get install libsoapysdr-dev
The biggest support headache is that source installs make it very easy to install multiple overlapping versions of the exact same software packages. This can manifest in cryptic errors, ABI incompatibilities, segfaults, missing drivers, and other unpredictable behavior.
Why installations can clash:
What version of a tool or library will your system pick? What should it pick? Source installations by default go to /usr/local and package installs typically to /usr. Typically binaries in /usr/bin and /usr/local/bin will both be part of the search PATH, and similarly /usr/lib and /usr/local/lib for the library search path (Note that your particular OS and .bashrc may vary).
Be very conscious of what is installed by the package manager!
Lets say you are building SoapySDR from source. Well, it could already be installed by your package manager! Perhaps it was pulled in by another package that depended on it, such has gr-osmosdr or limesuite.
- Fist recommendation: use the package manager, don't install this one from source (if you can).
- Second recommendation: remove this package and everything it depends on from the package manager. Any of the removed packages will also have to be built from source. In the chain of dependencies, once a node is built from source, so should all of its dependent nodes.
