This forces the linker ot use libatomic with clang on x86 (not only Android)
and forwards the intent to use libatomic to the shell's moz.build.
--HG--
extra : rebase_source : 0c803a3e11efcad3f17a462c2d38e85ec6cb556a
The moz.build Java JAR definitions are, of course, broken, but they
will be removed soon enough.
MozReview-Commit-ID: KIxqLDwd9I7
--HG--
extra : rebase_source : 8312b3f125793f73d3e835d1c0a5c7cabd4ebc0c
I choose to clean a bunch of ANDROID_* moz.build cruft here, too,
since it's just passing dependencies between moz.build and
Makefile.in. The replacement for all of this is to just use
GENERATED_FILES in moz.build, but it'll still take some work to get to
that. (Why does this stuff exist? GENERATED_FILES didn't exist and
was resisted when I built this stuff.)
MozReview-Commit-ID: D3GJqJNL0Ih
--HG--
extra : rebase_source : 07351f9d3702cfc42c58bd317885d07882c45c3a
NDK headers are grouped into a "sysroot" directory, which doesn't
contain architecture-specific bits, and a "system" directory, which
contains only the architecture-specific bits. Previously, both
directories are the same, under platforms/android-*/arch-*/. However,
with unified headers in NDK r16, the two are different, so we need to
support that in the Android build scripts.
Unified headers also rely on the build system defining the
__ANDROID_API__ macro, so we add support for that as well.
MozReview-Commit-ID: 9zBNQC3BRFl
--HG--
extra : rebase_source : 9ded282343df64d9cc4abcf7d7c6b03ac3423ff0
NDK headers are grouped into a "sysroot" directory, which doesn't
contain architecture-specific bits, and a "system" directory, which
contains only the architecture-specific bits. Previously, both
directories are the same, under platforms/android-*/arch-*/. However,
with unified headers in NDK r16, the two are different, so we need to
support that in the Android build scripts.
Unified headers also rely on the build system defining the
__ANDROID_API__ macro, so we add support for that as well.
MozReview-Commit-ID: 9zBNQC3BRFl
--HG--
extra : rebase_source : 36c9d4d5625fecbbe2485668811f85f9d94372d5
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : 5547e2c8fbf4e2e87182b8720d8352c131e4ec65
We no longer support Android/armv6 and we requires NEON for Android/arm, so
we can remove armv6 support for Android.
MozReview-Commit-ID: Hh17BTyE0wR
--HG--
extra : rebase_source : 57e043ecb1bb57a026c0b656b82768b899ddae78
Bug 1256642 introduced magic at the emitter level to determine whether a
binary contains C++ sources and should be linked with the C compiler or
the C++ compiler.
Unfortunately, the Binary() moz.build template always adds C++ OS
libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux
(stdc++compat).
The latter only ends up forcing every Binary() to be linked with the C++
linker, which is unfortunate, but doesn't cause much problems. The
former, however, involving OS libraries, the magic from bug 1256642
doesn't kick in, so we end up trying to link C++ OS libraries with the C
linker. Which ends up failing, because the libraries in STLPORT_LIBS
require -lm, which, while it's added by the C++ compiler when linking,
is not when the linkage is driven by the C compiler.
Because the fallible library, linked to all GeckoBinary()s is a C++
library, we still ended up linking with the C++ compiler on Android, so
this wasn't actually causing any problem... until I tried to remove that
fallible library in bug 1423803.
Anyways, the core problem is that moz.build evaluation is happening too
early to know whether any C++ sources are being linked together, so
there is no way the Binary() template can do the right thing. So this
change moves the logic to the emitter.
This also changes the type of STLPORT_LIBS to a list.
--HG--
extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : f7582d7089f0f4582a02aeaef090dc0701df994d
According to https://developer.android.com/ndk/guides/abis.html,
androideabi-v7a must support vfpv3-d16. So we should use it for fpu flag.
MozReview-Commit-ID: 3rhmRTekmwD
--HG--
extra : rebase_source : c5ffa22d8712fc7b8006cc340175a9586d77f49b
Stylo's bindgen is configured partially through a .toml.in file that
substitutes the value of a configure variable (BINDGEN_CFLAGS) into a
TOML list. We can debate whether this is a good thing to do some other
time; the reality is that the current moz.configure code that provides
the set_config for BINDGEN_CFLAGS needs to perform all the quoting
itself.
We want, however, to define the substituted variable in old-configure.in
land (some of the values that will go into BINDGEN_CFLAGS are only
defined in old-configure.in, and are not trivially ported to
moz.configure), which means that we need to have quoting logic in
m4/Python when we generate config.status. This patch adds an
appropriate macro for doing so.
The various AC_SUBST macros generate AC_SUBST_*FOO macros for holding the
values to substitute. The macros also cross-check the AC_SUBST_* macros
generated by other variants to make sure that you don't try to do
something like AC_SUBST(FOO) and AC_SUBST_SET(FOO). However, the check
in AC_SUBST_SET for AC_SUBST_LIST duplicate is missing an underscore:
the AC_SUBST_LIST macro generates another macro starting with
AC_SUBST_LIST_, but the AC_SUBST_SET macro checks for the prefix
AC_SUBST_LIST, which is missing the trailing underscore.
As we're going to be adding yet another AC_SUBST_* macro variant, and
therefore adding more checks to all existing macros, let's clean this up
before we start.
NDK r15+ clang changed the code generation strategy for the __atomic_*
intrinics such that using them with 64-bit types now requires linking
with libatomic. Our current configure tests for libatomic doesn't catch
this, because the std::atomic implementation is such that it doesn't
require an external library, even for 64-bit types, whereas the
__atomic_* intrinsics do. The safest thing to do is to force this
configure check to always return true when we are compiling for
x86/Android with clang.
The NDK clang needs to be informed about the existence of a GCC
toolchain, so important programs like the linker can be located. With
this change, we're starting to use command-line options that are
incompatible with GCC, so we also add a check to inform the user about
the non-support for this configuration.
While we're here, provide a reference to unique_list as defined in
moz.configure when executing config.data to avoid its redefinition
in m4.
MozReview-Commit-ID: AI6XhoYR0Ye
Although there is emulator command in android_sdk_root/tools even if Android
Tools 26, it doesn't work well because emulator64-arm is missing in same
directory.
Valild emulator command moves from android_sdk_root/tools to
android_sdk_root/emulator from Android Tools 26 (updated by sdkmanager).
MozReview-Commit-ID: 4IGHK3YcZXD
--HG--
extra : rebase_source : cc0c67f24c32a55ac40e65a5a036d5072dff6ee4
extra : histedit_source : 9718746e56dd9ec16a540533acfe909c319c234b
To build sytlo, we have to set compiler flags via BINDGEN_CFLAGS. Since we
pass stlport flags to clang, I would like to move STLPORT_CPPFLAGS to
moz.configure.
MozReview-Commit-ID: 26jvUqUvwTY
--HG--
extra : rebase_source : 5568627368fbf2dce02904918e50a241713d0a85
libstdc++ support is broken after moving to moz.configure. No one uses this option and NDK will remove GCC, so we should remove this and --with-android-cxx-stl option.
MozReview-Commit-ID: 3mqyHoRCE00
--HG--
extra : rebase_source : 35aa911a69e159e67f624ab5ab9aea8af4c5342f
cpu_arch_dir isn't absolute path, we cannot always detect thumb library for c++ library. Our build tool still uses NDK r11c, so we should check thumb library correctly.
MozReview-Commit-ID: 912ZDNeUcKc
--HG--
extra : rebase_source : 8b69348ef3280f32b7a228d66462070413a25e73
Some gaia-related code was also found and removed as part of the
cleanup.
MozReview-Commit-ID: DEjVSljzzu1
--HG--
extra : rebase_source : 58c4c34df44a258d90029853f29ea01338bd142b
This patch does two things:
- add a Gradle-only ANDROID_COMPILE_SDK_VERSION substitution;
- uses it while uniformizing all of the Gradle Android SDK version
configurations.
The approach is fairly standard (and we were using it already); see,
for example
https://medium.com/@ali.muzaffar/gradle-configure-variables-for-all-android-project-modules-in-one-place-5a6e56cd384e
This will make bumping the Gradle configuration versions forward
easier.
MozReview-Commit-ID: 1j5siCvR5qt
--HG--
extra : rebase_source : 07afb00de0e4a72af4026eb19ff4f2530c119336
This is just a small piece in the larger project of minimizing the set
of global AC_DEFINEs. None of these are relevant to C/C++ code;
they're mobile/android specific, so we should get them out of
mozilla-config.h.
In addition, this replaces hard-coded values with values from the
build system throughout mobile/android.
MozReview-Commit-ID: 9IJlsm38LFK
--HG--
extra : rebase_source : 0e55c0967cbb7f0df0d297eb330fc615e5759346
The -fsanitize=integer analysis from UBSan can be helpful to detect signed and unsigned integer overflows in the codebase. Unfortunately, those occur very frequently, making it impossible to test anything with it without the use of a huge blacklist. This patch includes a blacklist that is broad enough to silence everything that would drain performance too much. But even with this blacklist, neither tests nor fuzzing is "clean". We can however in the future combine this with static analysis to limit ourselves to interesting places to look at, or improve the dynamic analysis to omit typical benign overflows.
It also adds another attribute that can be used on functions. It is not used right now because it was initially easier to add things to the compile-time blacklist to get started.
Finally, it includes a runtime suppression list and patches various parts in the test harnesses to support that. It is currently empty and it should not be used on frequent overflows because it is expensive. However, it has the advantage that it can be used to differentiate between signed and unsigned overflows while the compile-time blacklist cannot do that. So it can be used to e.g. silence unsigned integer overflows on a file or function while still reporting signed issues. We can also use this suppression list for any other UBSan related suppressions, should we ever want to use other features from that sanitizer.
MozReview-Commit-ID: C5ofhfJdpCS
--HG--
extra : rebase_source : 952043a441b41b2f58ec4abc51ac15fa71fc142f
Benjamin Bouvier
Jeff Walden
shindli
Tom Ritter
Nick Alexander
David Major
Jim Chen
Cosmin Sabou
Mike Hommey
Matías Zúñiga
Makoto Kato
Bill McCloskey
Nathan Froyd
Chris Manchester
Jan Henning
Philip Chimento
Carsten "Tomcat" Book
Sebastian Kaspari
Gregory Szorc
mozilla@mozilla-23773
Sylvestre Ledru
Christian Holler
André Bargull