One less thing for configurations to vary is a good thing. This change
also means that when we do NDK bumps that introduce some kind of weird
incompatible change, configuration with a newly-pulled tree and an old
NDK halts at configure, rather than giving weird build errors.
Differential Revision: https://phabricator.services.mozilla.com/D44705
--HG--
extra : moz-landing-system : lando
We have an `ndk_version_major` and an `ndk_version_minor` that have a
lot of duplicated code in them. We could factor them into a single
function, but it seems better to just pull their logic into `ndk_version`
directly, rearranging that function to be IMHO more understandable.
Differential Revision: https://phabricator.services.mozilla.com/D44506
--HG--
extra : moz-landing-system : lando
Toolchain path for Windows version is `<NDK ROOT>/toolchains/llvm/prebuilt/windows-x86_64` etc, so it isn't '`winnt`.
So we has to replace `host.kernel.lower()` with `windows`.
Differential Revision: https://phabricator.services.mozilla.com/D39474
--HG--
extra : moz-landing-system : lando
Use the same logic as for --with-android-sdk to use the NDK downloaded
by mach bootstrap by default.
Differential Revision: https://phabricator.services.mozilla.com/D34251
--HG--
extra : moz-landing-system : lando
There is no concern that the Android NDK clang may not support it, as
the flag was added in clang 2.9. The flag is also not supported with
GCC, which is not ideal, but we already crossed that bridge at least
with -gcc-toolchain added in extra_toolchain_flags, which is not
supported by GCC either.
Differential Revision: https://phabricator.services.mozilla.com/D25019
--HG--
extra : moz-landing-system : lando
We shouldn't pass those flags when building C. It doesn't matter /too/
much currently, but will in a subsequent change, which will introduce
a C++-only flag in stlport_cppflags.
Differential Revision: https://phabricator.services.mozilla.com/D25018
--HG--
extra : moz-landing-system : lando
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
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
Now that extra_toolchain_flags includes stlport_cppflags, there's no
reason bindgen_cflags_defaults should depend on them both. So remove
the stlport_cppflags dependency. (There's no harm to multiply-including
stlport_cppflags, but not repeating -I options is good practice.)
extra_toolchain_flags is used for compiling target-specific bits of code
elsewhere in configure. Very shortly, we'll need to compile bits of
code that depend on the C++ standard library, so we'll want to point the
compiler at the C++ standard library. Making extra_toolchain_flags
include stlport_cppflags is the best way to do that.
extra_toolchain_flags is going to depend on stlport_cppflags
momentarily, so this commit is just for moving code around. Note that
the diff shows other things moving *after* stlport_cppflags.
We compute the same set of data in extra_toolchain_flags as we were
computing in bindgen_cflags_defaults. We might as well reuse the former
to compute the latter.
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.
Our normal method of locating the compilers in the NDK is to set
--with-toolchain-prefix when compiling for Android. However, the clang
binaries are in a different location than would otherwise be implied by
--with-toolchain-prefix. Additionally, we still need to know about
--with-toolchain-prefix because the NDK clang needs to be pointed there
so clang can find important binaries like the linker and because various
other bits of the build system depend on the --with-toolchain-prefix
value as well.
So we need a separate mechanism for communicating the whereabouts of the
NDK clang. We can't set CC and CXX because doing so would conflict with
the CC and CXX values exported to the js/src/ subconfigure. But Android
already has an extra_toolchain_flags function that we use for informing
moz.configure about additional flags needed solely for Android, and we
can use a similar trick to communicate the existence of the NDK's clang
to the main C/C++ compiler selection process.
Building Fennec/Android uses cross compiler toolchain. So we have to generate
clang options (include path for c++ headers and gcc headers, gcc-toolchain path and etc) from NDK path for bindgen.
The following options are required for android build.
(from stlport_cppflags)
-I$topsrcdir/android-ndk/sources/cxx-stl/llvm-libc++/libcxx/include
-I$topsrcdir/android-ndk/sources/android/support/include
-I$topsrcdir/android-ndk/sources/cxx-stl/llvm-libc++abi/libcxxabi/include"
(others for clang)
-isystem $topsrcdir/android-ndk/platforms/android-9/arch-arm/usr/include
-gcc-toolchain $topsrcdir/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64
-I$topsrcdir/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9/include
-I$topsrcdir/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9/include-fixed"
Also, since bindgen_cflags_defaults uses as default, some funcions requires '--help'.
MozReview-Commit-ID: 7zfhw3IxQ2W
--HG--
extra : rebase_source : 0ede4f0d1ec212cfe411f6abe0f55f4b0c70643d
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
gcc 4.9 is the last version in Android NDK and our minimum requirement of gcc is 4.9+. --with-android-gnu-compiler-version is unnecessary option because gcc version of Android is always 4.9.
MozReview-Commit-ID: 1sutqlvbQU5
--HG--
extra : rebase_source : 77e42aba81da5276bcddd945ea41895ce2461afa
Detect the NDK major/minor version numbers, and feed that to Breakpad.
For AArch64, some Breakpad headers try to workaround NDK oddities by
checking the ANDROID_NDK_MAJOR_VERSION and ANDROID_NDK_MINOR_VERSION
macros.
Importing 'os' in python configure functions, on Windows, changes the
separate the various os.path functions use, and that can have
unexpected, badly handled, consequences. While on the long term, it is
desirable to make @imports('os') modify os.path to use the same base
functions as if there were no @imports, let's go with the simpler
workaround of restoring the non-{isfile,isdir,exists} os.path functions
from b6be0e9e3e1e.
--HG--
extra : rebase_source : a1857b5dce2aa818c72a77d0d9727ac6ce16cb8f
