Using the have_neon boolean to enable NEON code means we have to either
fully enable it or fully disable it. When using -Dneon=runtime, ideally
only the parts that support runtime checks would be built for NEON, and
those that don't would be built without NEON. Though, there are no
longer any runtime checks for NEON anywhere, so it's equivalent to 'no'
with a warning.
In general, we should use have_* variables to indicate compiler support,
and *_opt options to choose if and how we want to utilize that. Use
neon_opt to control NEON compilation and avoid modifying have_neon which
now would fully refer to compiler support.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
We can set -Dneon=yes on x86, which will fail during build because the
x86 compiler doesn't understand the resulting `-mfpu=neon` flag. Make the
'neon' build option cause an error in the setup stage if we didn't
detect hardware support for NEON.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The default for the neon build option is 'no', which disabled NEON code
for 32-bit ARM but enabled it for ARM64. Now that 'no' can disable NEON
code for ARM64, the default should be 'auto' which would enable it where
possible. Handle the 'auto' value, and set it as the default.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The main if statment for the NEON option has been quite convoluted. The
previous commits reduced what it does to a simple case: check NEON
support and set have_neon on 32-bit ARM CPUs. Do that near the
architecture definitions.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
When the neon build option is set to 'no', we should disable optimized
implementations that use NEON. Change have_neon to false in that case,
so that we skip the flags and skip building NEON-specific files.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The WEBRTC_HAS_NEON macro that enables using NEON implementations is
unconditionally set for arm64 and the 'neon' build option is ignored,
assuming we always want to use the NEON-specific implementations instead
of generic ones. This is an OK assumption to make because arm64 CPUs
always support NEON.
But the code handling the build option ended up quite convoluted. As
part of cleaning up, set the relevant cflags after we handle the build
option. This also means that we can make 'runtime' fall back to 'no',
and disable NEON-specific code with -Dneon=no.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Upstream has dropped runtime checks for NEON instructions around 2016,
and the WEBRTC_DETECT_NEON macro is removed along with it. Disable NEON
when building with -Dneon=runtime and omit a warning instead.
Link: https://webrtc.googlesource.com/src/+/e305d956c0717a28ca88cd8547e5b310dfa74594
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
webrtc/rtc_base/checks.cc:158:28: error: use of undeclared identifier 'LAST_SYSTEM_ERROR'
158 | file, line, LAST_SYSTEM_ERROR, message);
| ^
webrtc/rtc_base/checks.cc:220:16: error: use of undeclared identifier 'LAST_SYSTEM_ERROR'
220 | LAST_SYSTEM_ERROR);
| ^
In file included from webrtc/rtc_base/platform_thread_types.cc:11:
webrtc/rtc_base/platform_thread_types.h:47:1: error: unknown type name 'PlatformThreadId'
47 | PlatformThreadId CurrentThreadId();
| ^
webrtc/rtc_base/platform_thread_types.h:52:1: error: unknown type name 'PlatformThreadRef'
52 | PlatformThreadRef CurrentThreadRef();
| ^
webrtc/rtc_base/platform_thread_types.h:55:29: error: unknown type name 'PlatformThreadRef'
55 | bool IsThreadRefEqual(const PlatformThreadRef& a, const PlatformThreadRef& b);
| ^
webrtc/rtc_base/platform_thread_types.h:55:57: error: unknown type name 'PlatformThreadRef'
55 | bool IsThreadRefEqual(const PlatformThreadRef& a, const PlatformThreadRef& b);
| ^
webrtc/rtc_base/platform_thread_types.cc:37:1: error: unknown type name 'PlatformThreadId'
37 | PlatformThreadId CurrentThreadId() {
| ^
webrtc/rtc_base/platform_thread_types.cc:58:1: error: unknown type name 'PlatformThreadRef'
58 | PlatformThreadRef CurrentThreadRef() {
| ^
webrtc/rtc_base/platform_thread_types.cc:68:29: error: unknown type name 'PlatformThreadRef'
68 | bool IsThreadRefEqual(const PlatformThreadRef& a, const PlatformThreadRef& b) {
| ^
webrtc/rtc_base/platform_thread_types.cc:68:57: error: unknown type name 'PlatformThreadRef'
68 | bool IsThreadRefEqual(const PlatformThreadRef& a, const PlatformThreadRef& b) {
| ^
In file included from webrtc/rtc_base/event_tracer.cc:30:
In file included from webrtc/api/sequence_checker.h:15:
In file included from webrtc/rtc_base/synchronization/sequence_checker_internal.h:18:
webrtc/rtc_base/synchronization/mutex.h:28:2: error: Unsupported platform.
28 | #error Unsupported platform.
| ^
webrtc/rtc_base/synchronization/mutex.h:52:3: error: unknown type name 'MutexImpl'
52 | MutexImpl impl_;
| ^
The top-level meson.build file adds WEBRTC_ARCH_MIPS_FAMILY to
arch_cflags for mips architectures, which causes the following error:
[1/306] Compiling C++ object webrtc/rtc_base/liblibbase.a.p/synchronization_yield.cc.o
FAILED: webrtc/rtc_base/liblibbase.a.p/synchronization_yield.cc.o
c++ [...] -DWEBRTC_THREAD_RR WEBRTC_ARCH_MIPS_FAMILY -MD [...] ../webrtc/rtc_base/synchronization/yield.cc
c++: warning: WEBRTC_ARCH_MIPS_FAMILY: linker input file unused because linking not done
c++: error: WEBRTC_ARCH_MIPS_FAMILY: linker input file not found: No such file or directory
It is supposed to be "-DWEBRTC_ARCH_MIPS_FAMILY". But, that macro is
already defined in arch.h when building for mips:
[30/306] Compiling C++ object webrtc/system_wrappers/libsystem_wrappers.a.p/source_cpu_features.cc.o
In file included from ../webrtc/system_wrappers/source/cpu_features.cc:13:
../webrtc/rtc_base/system/arch.h:47:9: warning: "WEBRTC_ARCH_MIPS_FAMILY" redefined
47 | #define WEBRTC_ARCH_MIPS_FAMILY
| ^~~~~~~~~~~~~~~~~~~~~~~
<command-line>: note: this is the location of the previous definition
Drop the broken, unnecessary argument from cflags.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Ongoing fixes and improvements, transient suppressor is gone. Also,
dropping isac because it doesn't seem to be useful, and is just build
system deadweight now.
Upstream references:
Version: 131.0.6778.200
WebRTC: 79aff54b0fa9238ce3518dd9eaf9610cd6f22e82
Chromium: 2a19506ad24af755f2a215a4c61f775393e0db42
Some API deprecation -- ExperimentalAgc and ExperimentalNs are gone.
We're continuing to carry iSAC even though it's gone upstream, but maybe
we'll want to drop that soon.
Undefining this macro makes GCC in standards C++ mode very unhappy:
In file included from D:/msys64/ucrt64/include/c++/13.2.0/bits/requires_hosted.h:31,
from D:/msys64/ucrt64/include/c++/13.2.0/string:38,
from ..\subprojects\webrtc-audio-processing\webrtc/rtc_base/system/file_wrapper.h:17,
from ../subprojects/webrtc-audio-processing/webrtc/rtc_base/system/file_wrapper.cc:11:
D:/msys64/ucrt64/include/c++/13.2.0/x86_64-w64-mingw32/bits/c++config.h:666:2: warning: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" [-Wcpp]
666 | #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported"
| ^~~~~~~
See: https://github.com/fmtlib/fmt/issues/2059#issue-761209068
See: #32
Too much information was specified manually. All this is deduced
automatically if you specify the library as the first positional
argument.
Only absl_base needs to be in Requires: because absl_optional's header
file is needed at build time.
Also add a check in the CI for the pc files being usable.
Simplify fallback, and prefer it. `[provide]` section requires meson
0.55, so require that.
pkg-config lookup is only provided for distros, since they dislike
static linking / vendoring.
* Rename Windows.h uses to windows.h
* Comment out structured exception handling usage
Makes MinGW happier. Mostly the same as previous work by
Nicolas Dufresne <nicolas.dufresne@collabora.com>, with the exception
that we now don't try to invoke RaiseException which would fail in MinGW
as it raises a Windows structured exception.
This should help for cases where users can make abseil-cpp available but
wiring up the CMake-build isn't that easy (for example, while
cross-compiling).
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.
