Since we cannot rely on the API to be stable upstream, let's start
making the pkg-config, library, and include dir have a version suffix.
This will allow different downstream projects depending on us to
independently switch versions without packagers having to jump through
hoops.
This new lib contains the bare minimum to implement an iSAC encoder and
decoder.
The webrtc files have been copied from the revision as the existing
imported files (c8b569e0a7ad0b369e15f0197b3a558699ec8efa).
The bug preventing us to pass the library object to
pkgconfig.generate() has been fixed in meson 0.52.
By doing so the generated pc file has the right -L linker flag, making
it easier to test the lib from non standard location.
We also no longer have to pass libraries_private, it will handle it
automatically.
Make *really* take '--with-ns-mode'-option into account.
Before it was bogus (wrong if-check) and it always resulted
in the float version being used.
Signed-off-by: Mirko Vogt <mirko-dev@nanl.de>
The current architecture detection, based on the "host_cpu" part of the
tuple does not work properly for a number of reason:
- The code assumes that if host_cpu starts with "arm" then ARM
instructions are available, which is incorrect. Indeed, Cortex-M
platforms can run Linux, they are ARM platforms (so host_cpu = arm),
but they don't support ARM instructions: they support only the
Thumb-2 instruction set.
- The armv7 case is also not very useful, as it is not standard at all
to pass armv7 as host_cpu even if the host system is actually ARMv7
based.
- For the same reason, the armv8 case is not very useful: ARMv8 is
AArch64, and there is already a separate case to handle this
architecture.
So, this commit moves away from a host_cpu based logic, and instead
tests using AC_CHECK_DECLS() the built-in definitions of the compiler:
- If we have __ARM_ARCH_ISA_ARM defined, then it's an ARM processor
that supports the ARM instruction set (this allows to exclude Thumb-2
only processors).
- If we have __ARM_ARCH_7A__, then we have an ARMv7-A processor, and
we can enable the corresponding optimizations
- Same for __aarch64__, __i386__ and __x86_64__.
In addition, we remove the AC_MSG_ERROR() that makes the build fail for
all architectures but the ones that are explicitly supported. Indeed,
webrtc-audio-processing builds just fine for other architectures (tested
on MIPS), it's just that none of the architecture-specific optimizations
will be used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In investigating x86/sse2 issues in recent webrtc-audio-processing-0.2
release, I found that it was possible for libwebrtc_audio_processing to
contain undefined symbols.
Attached is a patch that addresses this:
* adds -Wl,--no-undefined to libwebrtc_audio_processing_la_LDFLAGS
* adds explicit -lpthread linkage (else, there are undefined references
to pthread-related symbols)
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
