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.
Instead of specifying a class name per line, the new format uses the
.ini format, with each section name specifying the class, and each
property name specifying a member of the class. WrapForJNI options can
be specified with each class or member. Comments can be specified with
';' or '#'. For example,
# Generate bindings for Bundle using default options:
[android.os.Bundle]
# Generate bindings for Bundle using class options:
[android.os.Bundle = exceptionMode:nsresult]
# Generate bindings for Bundle using method options:
[android.os.Bundle]
putInt = stubName:PutInteger
# Generate bindings for Bundle using class options with method override:
# (note that all options are overriden at the same time.)
[android.os.Bundle = exceptionMode:nsresult]
# putInt will have stubName "PutInteger", and exceptionMode of "abort"
putInt = stubName:PutInteger
# putChar will have stubName "PutCharacter", and exceptionMode of "nsresult"
putChar = stubName:PutCharacter, exceptionMode:nsresult
# Overloded methods can be specified using its signature
[android.os.Bundle]
# Skip the copy constructor
<init>(Landroid/os/Bundle;)V = skip:true
# Generic member types can be specified
[android.view.KeyEvent = skip:true]
# Skip everything except fields
<field> = skip:false
# Skip everything except putInt and putChar
[android.os.Bundle = skip:true]
putInt = skip:false
putChar =
# Avoid conflicts in native bindings
[android.os.Bundle]
# Bundle(PersistableBundle) native binding can conflict with Bundle(ClassLoader)
<init>(Landroid/os/PersistableBundle;)V = stubName:NewFromPersistableBundle
# Generate a getter instead of a literal for certain runtime constants
[android.os.Build$VERSION = skip:true]
SDK_INT = noLiteral:true
For static final fields, generate a getter instead of a literal when
specified. Used to generate bindings for runtime constants whose values
are unknown at compile time.
Also remove bits of a comment, now that we support only macOS 10.9+, most of the
comment isn't relevant.
While PIE is enabled by default on macOS, this isn't true of clang on Linux.
--enable-pie can now be used with clang on Linux.
r=froydnj
MozReview-Commit-ID: rc6zJiWzLo
--HG--
extra : rebase_source : 3745175e106ea8c6be9271d8135d43ba359434c7
For linking static libraries, rustc will use whatever `cc` it finds (or
the equivalent on Windows). For our purposes, however, `cc` is not what
we use to link and we may have additional options we would like to pass
to the linker.
To do this, we need to tell Cargo about our alternate linker (currently
only used for target compilations, on the theory that the host compiler
rustc finds is probably good enough) and we also need to pass our linker
options into the process. We do this with environment variables, which
is not a great solution, but works surprisingly well.
This alternate linker is disabled for ASan builds due to peculiar
crashes when running Rust build scripts and for Windows, because we
don't do any interesting cross-compiling there.
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 90f79b6f4a2d8d925dd20eb0bf6ab96262c227d5
rustc generates .lib files for its libraries when compiling for Windows
(even using MinGW on Linux). But MinGW expects .a files. So we add in
rust-specific prefix and suffixes so MinGW builds can find the libs that
rustc generates. (And the RUST_LIB- variables default to the same vales
as the LIB_ variables otherwise.)
MozReview-Commit-ID: ClsA0YuJaxh
--HG--
extra : rebase_source : 7b46460c94ceb34b7a5a302ce91d3f1dca600041
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 15c69aeca3295a1811c85a9cf4c2793312dcd122
This flag enables the stack-cookie exploit mitigation for all functions which
manipulate stack-based buffers, providing better protections than
-fstack-protector, at considerably lower performance overhead than
-fstack-protector-all.
r=froydnj
MozReview-Commit-ID: 7ZNAHHAf376
--HG--
extra : rebase_source : 6d5ccbb9537372912c3f5a73fe0fdc65bb68ac08
Warn about possible misuse of the comma operator such as between two statements or to call a function for side effects within an expression. Only enable these -Wcomma warnings for C++ code because there are almost two hundred -Wcomma warnings in third-party C libraries. I reviewed the C warnings and confirmed none of them were latent bugs. We won't fix these libraries' warnings so they are just noise.
MozReview-Commit-ID: 1JXJumg6DsJ
--HG--
extra : rebase_source : c48189653361aa84edd3004188315cd73aefa9b5
extra : amend_source : 30be5afeb03eff26d59ccde57c0eb547b743c304
MINGW builds do not need any of the checks that are performed in the
windows.configure file. Nor do they the D3D compiler DLL that is
needed for ANGLE, so we can skip that entire section in
old-configure.in.
MozReview-Commit-ID: DqufbgGoGy4
--HG--
extra : rebase_source : d5f1ed371f79a8a16f888ccc5d058ac72a69f34f
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
Most entries in virtualenv_packages.txt that are .pth or packages.txt
are currently in SEARCH_PATHS in mach_bootstrap. The ones that are
missing would make sense in SEARCH_PATHS. None of non-.pth or
packages.txt entries, however, are in SEARCH_PATHS and don't make sense
there.
On the other hand, virtualenv_packages.txt misses a lot of things that
are in SEARCH_PATHS, all of which should be there. One exception:
xpcom/idl-parser, which causes problems due to the xpidl package
containing an xpidl module, which causes problems with the in-tree
scripts using it. Plus, it needs a cache directory, which is messy, so
it's preferable to keep it away from the virtualenv. It turns out it was
added to mach_bootstrap.py in bug 893976 for a command that was since
then removed (bug 1244736), so we can get away with removing it.
So instead of keeping those two separate lists out of sync, we replace
the SEARCH_PATHS list from mach_bootstrap with one that is derived at
runtime from the contents of virtualenv_packages.txt.
And since a .pth can't fail to install in the virtualenv, it makes no
sense to have psutil.pth defined as optional, which allows it to end up
in the mach_bootstrap search path automatically.
Finally, because we do have overlapping module names in the tree (e.g.
runtests), and mach_bootstrap's SEARCH_PATHS had a guaranteed order,
we change the order of the virtualenv_packages.txt file to match what
used to be in mach_bootstrap, and make all the pth entries use the same
file name so that the order is more guaranteed in the virtualenv too.
--HG--
extra : rebase_source : 5bd09f2f984d6f78a76b38e768d8a67806af5954
This adds a unit test for the expected behavior, and adds the modules
from mach_bootstrap.py that are missing in the virtualenv for the test
to run.
--HG--
extra : rebase_source : e34d0474cfb6c8c5ce9cd847b96de88906191923
These dependencies are no longer relevant now that we're dumping symbols
for individual programs and libraries during the compile tier. The
automation/buildsymbols target now corresponds to archiving the
dumped symbols, and does not modify programs and libraries.
MozReview-Commit-ID: IQYIaVoqVJN
--HG--
extra : rebase_source : 1eb6d36b20381be77264cf01323850747bd94d1c
The TASKCLUSTER_WORKER_GROUP environment variable used to contain the full
AWS availability zone, but a recent docker-worker change changed it to
be simply the AWS region, which broke sccache in taskcluster because we
were using it as part of the S3 bucket name.
MozReview-Commit-ID: 1KsfWpB4PoY
--HG--
extra : rebase_source : bdc61f180bf079eb0ad2cdbbd25e3e3a0deb62e6
When the clang plugin is used, building something during export needs to
happen after the plugin is built. But there is no dependency ensuring
this happens.
OTOH, these sources in elfhack/inject don't need to be built that early,
so we'll just leave to the build system to build it at a proper time.
--HG--
extra : rebase_source : a6bef8ec6eece3a1b0e45f84c907c2fbc0800863
It looks like Google decided to split these jars out a bit, so we need to piece
them all back together.
We could probably just query the sdk version instead, but I'm not 100% sure
know when this setup changed - moreover we don't know when (if?) the paths
are likely to change again. SDK 26.0 still has lint 25.3.1, so the SDK and
lint versions don't appear to be tied.
It seems that only the lint* jars are needed to compile 'build/annotationProcessor',
however we need all the remaining jars in the classpath when running that code
in 'widget/android/bindings'.
MozReview-Commit-ID: GAKwMrVXW55
--HG--
extra : rebase_source : 4e790aaccae8ccc3f151c39bf1ef4404b2581d7a
