This adds flexible plugin-like loading of the individual RF
implementations (zmq, uhd, soapy,...) as per availability at runtime.
Unlike before, the binary application is not terminated if the
dependencies of individual RF interfaces are not installed on the
executing system. To do this, the plugins are not linked by the linker
at compile time, but opened at runtime via dlopen() and dropped in case
of failure due to missing dependencies.
For Ubuntu 18.04: Linking the static srsran_rf to libuhd
also requires to link Boost's "system" library.
Newer systems do not require this special handling.
TSAN doesn't work well then threads are created with attributes
thar require root rights but the process is run as normal user.
this patch avoid the thread attributes in this case. TSAN isn't going
to be used for production builds.
this fixes a linking problem with RPi 3 (and probably others) running
with Raspbian (new Raspberry Pi OS) that can't use the inline
atomic functions but instead require linking against the lib -latomic.
The CMake code is based on SoapyRTLSdr file (licensed under MIT)
https://github.com/pothosware/SoapyRTLSDR/blob/master/CheckAtomic.cmake
this allows to limit the number of compile jobs to e.g. one or two
which is needed when using parallel build systems like Ninja on
resource (RAM) contrained systems, like the RPi4
gcc sets the inlining limit a bit arbitrary and the default gcc
on the RPi2 seems to use a lower value so compiling the SIMD
extensions fails with an "inlining failed" error in
srslte_mat_2x2_mmse_csi_simd().
this patch increases the default value. even though its
increased for all platforms it shouldn't case issues on other
machines. the value isn't used by clang.
we've added this to allow building for older glibc
version that cause issues with redefining some structs.
this patch removes the flag and auto-detects it using the glibc version
`AUTO_DETECT_ISA` will disable the resolution of the SSE packages
and the user will have to manually set `HAVE_{AVX,AVX2,SSE}`.
Solves #453
Signed-off-by: Filipe Laíns <lains@archlinux.org>