Linking with -latomic has been added to pipewire-jack since
b8c58c74d8
However, this is not the right place to add this dependency, atomic_dep
should be added to pipewire_dep to avoid the following build failure:
/home/giuliobenetti/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/sparc-buildroot-linux-uclibc/9.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: src/pipewire/libpipewire-0.3.so.0.326.0.p/filter.c.o: in function `impl_node_process':
filter.c:(.text+0xf28): undefined reference to `__atomic_fetch_add_4'
Indeed, atomic operation such as __atomic_fetch_add is used in libcamera
as well as in ./spa/plugins/libcamera/libcamera_wrapper.cpp,
./spa/include/spa/utils/ringbuffer.h and ./spa/include/spa/graph/graph.h
Fixes:
- http://autobuild.buildroot.org/results/b5305e8e7dd1a5e8bfaba72b06251056ba7d1af1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This is necessary on some 32-bit architectures that implement atomic
operations on 64-bit quantities as library calls, including Debian's
armel and mipsel ports.
Signed-off-by: Simon McVittie <smcv@debian.org>
This makes it easier to test PipeWire in its "as-installed" state,
for example in an OS distribution.
The .test metadata files in ${datadir}/installed-tests/${package} are
a convention taken from GNOME's installed-tests initiative, allowing a
generic test-runner like gnome-desktop-testing to discover and run tests
in an automatic way.
The installation path ${libexecdir}/installed-tests/${package} is also
a convention borrowed from GNOME's installed-tests initiative.
In addition to the automated tests, I've installed example executables
in the same place, for manual testing. They could be separated into
a different directory if desired, but they seem like they have more
similarities with the automated tests than differences: both are there
to test that PipeWire works correctly, and neither should be relied on
for production use. Some examples are installed in deeper subdirectories
to avoid name clashes.
Signed-off-by: Simon McVittie <smcv@debian.org>
On GNU/Linux systems, the literal string '${LIB}' in dynamic linker
paths expands to "lib", a biarch libQUAL directory such as "lib64", or
a Debian-style multiarch directory such as "lib/x86_64-linux-gnu".
If we're installing libraries to such a directory, and we have both
word-sizes' compatibility libraries available, then pw-pulse can
use LD_LIBRARY_PATH='/usr/${LIB}/pipewire-0.3/pulse' to make both
i386 and x86_64 programs load the correct version.
Signed-off-by: Simon McVittie <smcv@debian.org>
Don't use a special name for the replacement libraries but install
them into the modules directory by default. Add an option to install
them into another location.
This way, we don't need to set up symlinks in development, distros can
choose to install them where they want and/or we can use symlinks or
LD_LIBRARY path to select the replacement versions.