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.
