Suppress leaks for allocations where any stack frame matches the string
style::gecko::global_style_data. This could be dangerous if someone were to
allocate non-global things with this on the stack, but hopefully that can be
avoided, given the name of the module.
MozReview-Commit-ID: 65HpUGsgPPM
--HG--
extra : rebase_source : 19ba5a5001de65628acdb0433341d14429e4af67
GYP of WebRTC should reference MOZ_SYSTEM_LIBEVENT values if available.
MozReview-Commit-ID: CshsPrRidM8
--HG--
extra : rebase_source : 9e619c2f49e7c2b3f680814b95b823996773fa6c
In some cases, we can end up linking some things with
--static-libstdc++. The notable (only?) example of that is for the
clang-plugin, and that happens because it gets some of its flags from
llvm-config, which contains --static-libstdc++ because clang itself is
built that way.
When that happens, the combination of --static-libstdc++ and
stdc++compat breaks the build because they have conflicting symbols,
which is very much by design.
There are two ways out of this:
- avoiding either -static-libstdc++ or stdc++compat
- work around the symbol conflicts
The former is not totally reliable ; we'd have to accurately determine
if we're in a potentially conflicting case, and remove one of the two in
that case, and while we can do that for the cases we explicitly know
about, that's not future-proof, and might fail just as much in the
future.
So we go with the latter. The way we do this is by defining all the
std++compat symbols weak, such that at link time, they're overridden by
any symbol with the same name. When building with -static-libstdc++,
libstdc++.a provides those symbols so the linker eliminates the weak
ones. When not building with -static-libstdc++, the linker keeps the
symbols from stdc++compat. That last assertion is validated by the
long-standing CHECK_STDCXX test that we run when linking shared
libraries and programs.
That still leaves the symbols weak in the final shared
libraries/programs, which is a change from the current setup, but
shouldn't cause problems because when using versions of libstdc++.so
that do provide those symbols, it's fine to use the libstdc++.so version
anyways.
Bump the minimum required version of the Rust toolchain to
the current stable release so we can take advantage of new
features.
Highlights of the 1.19.0 release:
* C-compatible `union` (untagged enums).
* Support for Visual Studio 2017.
* Non-capturing closures can be coerced to `fn` bindings.
* Numeric field names in tuple struct initializers.
* Higher macro recursion limit.
* `break` can return a value from `loop` expressions.
* Better error handling with mis-configured Visual Studio environments.
This change also enables 1.18.0 features. Some highlights:
* `pub(mod)` &c. for better control of symbol visibility.
* struct packing for better memory footprint in generated code.
* Faster build times.
MozReview-Commit-ID: 2OpUjAcytpE
--HG--
extra : rebase_source : 2ed0d7c4e7b78c26f7a7476e7b284bf1bdbe7c8b
Mostly removals, but also adding docs on how to create a
multilingual package right now.
I think I'd like to take another pass at those docs in a follow-up.
MozReview-Commit-ID: Dkw4MJ5DLyb
--HG--
extra : rebase_source : 4f79499e376cf6ddd23169a1c4525ed6b551a740
It becomes a library of some sort, so that multiple scripts can benefit
from it to build different versions of GCC.
The GPG key associated with GCC is also refreshed from keys.gnupg.net,
adding a new subkey, used to sign newer versions of GCC (and
postprocessed with pgpstrip to make it smaller).
We're soon going to build multiple versions of clang and gcc for linux,
and we need to differentiate them. Furthermore, there is a need for the
base-toolchains builds to use a fixed version of clang and gcc. So
rename the clang and gcc toolchain jobs to include their version, add
aliases to satisfy all existing jobs, and adjust the base-toolchains
jobs to use the explicit version.
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-3.9-linux64.json
rename : taskcluster/scripts/misc/build-gcc-linux.sh => taskcluster/scripts/misc/build-gcc-4.9-linux.sh
The lld linker creates separate segments for purely executable sections
(such as .text) and sections preceding those (such as .rel.dyn). Neither
gold nor bfd ld do that, and just put all those sections in the same
executable segment.
Since elfhack is putting its executable code between the two relocation
sections, it ends up in a non-executable segment, leading to a crash
when it's time to run that code.
We thus insert the elfhack code before the first executable section
instead of between the two relocation sections (which is where the
elfhack data lies, and stays).
--HG--
extra : rebase_source : ab18eb9ac518d69a8639ad0e785741395b662112
Since bug 635961, building with relro makes elfhack try to use the bss
data for a temporary function pointer. If there is not enough space for
a pointer in the bss, elfhack will complain it couldn't find the bss.
In normal circumstances, this is most likely fine. Libraries with a bss
so small that it can't fit a pointer are already too small to be
elfhacked anyways. In Firefox, the two libraries with the smallest bss
have enough space for two pointers, and aren't elfhacked (libmozgtk.so
and libplds4.so).
However, the testcase that is used during the build to validate that
elfhack works doesn't have a large enough bss on x86-64, making elfhack
bail out, and the build fail as a consequence.
This, in turn, is due to the only non-thread-local zeroed data being an
int, which is not enough to fit a pointer on x86-64. We thus make it a
size_t.
--HG--
extra : rebase_source : bca2ddbf9d4a5e8786881fc524d642c38d610227
Configure now detects VCS info. Configure now detects Watchman.
We can combine the two so configure can detect if Mercurial
is configured with Watchman enabled.
This commit does two things:
1) collects the Mercurial config so it is available to downstream checks
2) examines the config for presence and state of the fsmonitor
extension
We don't yet do anything with the fsmonitor state. But it should be
useful soon. Also, the return value is kinda wonky. This will almost
certainly be improved as soon as there is an actual consumer.
MozReview-Commit-ID: HyHZ2X8VI0h
--HG--
extra : rebase_source : e53928127470340275f0c0f07db72b536bba885b
extra : source : a8373914cbfd9b8595fc24f36c876cab0a26c02a
Often you only want to evaluate a function if all its dependencies
are true. Expressing this in a "when" can be difficult. So let's
add a convenience decorator for it.
The existing code for @depends_if() was refactored to take an
evaluation function as its first argument. This prevents some
duplicate code and turns @depends_if() and @depends_all() into
one-liners.
MozReview-Commit-ID: Jbugvf0lioM
--HG--
extra : rebase_source : 177741b80ac4fbfb547d6b36a6f5777fe514d91a
extra : source : 0c2bc12f4ebe44428385745266d2fd158e0c3382
Build Stylo (the styling system from servo) by default in all
builds for win32, win64, macOS and linux64 targets. It was
previously enabled for automation builds, so this just changes
the behaviour for local developer builds.
Note that this introduces a new dependency on libclang for the
binding generator. If you're developing on a tier-1 platform,
run `./mach boostrap` to install a working copy. Otherwise
llvm+libclang 4.0.1 is recommended.
Remove the explicit --enable-stylo=build in mozconfig.stylo
in favour of the configure default.
Add mozconfig.stylo to the hazard and debug-asan mozconfigs
so LLVM_CONFIG is defined properly for those builds.
Based on a patch by Bobby Holly in bug 1356991.
MozReview-Commit-ID: C2wRNl7JHpz
--HG--
extra : rebase_source : 1ed7c36a64e25b235a26864592cd7ea969a4cd25
Configure now detects VCS info. Configure now detects Watchman.
We can combine the two so configure can detect if Mercurial
is configured with Watchman enabled.
This commit does two things:
1) collects the Mercurial config so it is available to downstream checks
2) examines the config for presence and state of the fsmonitor
extension
We don't yet do anything with the fsmonitor state. But it should be
useful soon. Also, the return value is kinda wonky. This will almost
certainly be improved as soon as there is an actual consumer.
MozReview-Commit-ID: HyHZ2X8VI0h
--HG--
extra : rebase_source : d245d316cc8a27b2827b7824204549b91465bd34
Often you only want to evaluate a function if all its dependencies
are true. Expressing this in a "when" can be difficult. So let's
add a convenience decorator for it.
The existing code for @depends_if() was refactored to take an
evaluation function as its first argument. This prevents some
duplicate code and turns @depends_if() and @depends_all() into
one-liners.
MozReview-Commit-ID: Jbugvf0lioM
--HG--
extra : rebase_source : 38b4af7b668830589126e8a83f5d5ab73914d07c
In bug 1181040, we added ${var}_IS_SET variables for
mk_add_options-defined variables. In the two years since, that has never
been used for anything else than MOZ_PGO_IS_SET, and the only use for
that has now been removed, so remove those ${var}_IS_SET variables.
--HG--
extra : rebase_source : 2fc9abe0c3badbf06f3858fcf326237e67891fee
Note this will only enable it on try, autoland and mozilla-inbound,
which are the only branches where sccache are enabled at the moment.
Enabling on more builds (or not) is the subject of bug 1373460.
Also note that bug 1181040, that ensured PGO builds weren't using
sccache mentions that back then, link times went up when using sccache
(with -Z7) vs. without, but that was presumably with MSVC 2013. Try
suggests link times are the same using sccache now (still using -Z7,
pending bug 1318370).
--HG--
extra : rebase_source : 9f9d87714f3c841b790eb7d692ea0968b1755b70
We want most builds to be actually using sccache, so we include
mozconfig.cache from mozconfig.common. However, since the --with-ccache
configure option doesn't exist on non-compile jobs (e.g. artifact
builds), we move to using the CCACHE environment variable instead, which
allows us to unset it in mozconfig.no-compile.
And since mozconfig.no-compile is always included where no_sccache is
set, we can remove that variable.
--HG--
extra : rebase_source : a8c743de1fd7a3c0fbc53f7c233df36585897767
