B2g came with its own version of 'libgabi++' in its toolchain. Gecko
on b2g isn't build any longer with this toolchain. With this patch
applied, Gecko's internal version of 'libgabi++' is used for building.
MozReview-Commit-ID: KU4OBYQ6cAW
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 22ab4f47661ead4995d0c5261104abfb02b82aa2
Previously this implementation would use the expected names of the built-in
module and slot to get a handle on them. This doesn't work on distributions that
use other names. The new implementation searches through the slots from the
default module list for one where PK11_HasRootCerts returns true (which
indicates that NSS considers that slot to contain the default built-in root
list).
MozReview-Commit-ID: LmX27hQfFJU
--HG--
extra : rebase_source : 50383dcc77257fe08ce2c7d908e95cda7c4bbe9d
This also fixes the issue of processing the artifacts twice in some
situations (bug 1275673). Note that the artifact download no longer
happens when a specific target is passed to 'mach build'.
MozReview-Commit-ID: Ktys6u3r1kG
Historically, a mozinfo for js standalone build has not been necessary,
but with the move towards a) having things work with mach and b)
buildconfig using the MozbuildObject.from_environment in next patch,
mozinfo becomes necessary (it's required for
MozbuildObject.from_environment to find the directory is an objdir).
Interestingly, hazard builds do both a js standalone build and a desktop
Firefox build at the same time, both of which are done with MOZCONFIG
set in the environment... with the Firefox mozconfig. The result of now
writing a mozinfo for js standalone builds is that in that case, they
end up with a reference to the mozconfig, which the build system then
reads, and finds a MOZ_OBJDIR, which then doesn't match the js
standalone build objdir. So for those builds, reset MOZCONFIG.
Until now, we had some STL headers listed in the system-headers list
such that they would get a system wrapper, but not all of them.
On the other hand, the STL wrappers do the same job as the system
wrappers (applying default visibility), on top of their own, so the
presence of the STL headers in system-headers wasn't making much of a
difference.
Except we have places in the tree where we can't build with STL wrappers
for a number of reasons. And in that case, we *do* need system wrappers
for the STL headers, but we didn't have system wrappers for all of them.
So instead of relying on the STL headers being listed both in
system-headers and stl-headers, concatenate both lists to create the
system wrappers.
Similarly to the considerations about glibc, the Linux compatibility matrix
(https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix)
tells us no distro with Gtk+3 3.4 has a version of libstdc++ older than
4.6.
The data in the matrix doesn't go to that level of detail, but Ubuntu
12.04 LTS, being the only one with version 4.6 (others have at least
4.7), it's worth noting it has version 4.6.3. Which means we can safely
require libstdc++ symbols version 3.4.16 (which were added in 4.6.1).
This will allow us to remove a lot of the stdc++ compatibility hacks.
The requirement for glibc has been set to version 2.7 for a long while.
Spidermonkey uses the pthread_setname_np symbol, which is only available
since glibc 2.12. So far, we've been fortunate that the symbol doesn't
end up in libxul, or tests that link to js directly, because the symbol
is eliminated as being called by effectively dead code.
There are multiple reasons why this is going to change, one of which
being changes to the way things are linked, that will make the linker
not eliminate that code in some cases. Another is that eventually, the
separation of build systems between js and top-level is going to fade,
and the glibc checks, which apply to all gecko binaries, will also apply
to js binaries. They currently are not happening, and would fail because
of pthread_setname_np if they were.
Taking a step back, as of version 46, the mozilla.org builds require at
least Gtk+3 3.4. Which means the requirements for the underlying system
have received a dramatic bump, and it's time to revisit the requirements
for binary compatibility.
I went through all my notes from all the recent times binary compatibility
has been considered, and put together a compatibility matrix on MDN from
that data as well as more recent data that I could find here and there,
about the major non-rolling-release distros (RHEL, Fedora, SuSE, Debian,
Ubuntu)
https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix
Considering the data there, none of the distros that have at least Gtk+3
3.4 have a glibc older than 2.13. The list of symbols that 2.13 provides
that 2.12 doesn't have is not large enough, though, to really care about
depending on 2.13.
This uses a rough form of prefix matching, considering anything that ends in a
path separator and appears as a prefix of a file to be a directory.
MozReview-Commit-ID: 7FJSxI0fBSA
--HG--
extra : rebase_source : e4cece21a25ac1216d96647963955459d0f964e5
By bug 1270621, ETW support is removed. So no one uses messege compiler.
MozReview-Commit-ID: HGUAkrb208N
--HG--
extra : rebase_source : 5178283b781e4805b4e97f09b35a4150119d060a
extra : histedit_source : 40d6992894315b51863db4e7697df1c1ef18edd8
The intent in bug 1271829 was to make all the XCFLAGS set in
config/external/nss/Makefile.in accumulate instead of replacing each
other. Unfortunately, there is also an AC_SUBST variable named XCFLAGS,
use for other purposes, and we ended up adding on top of that variable.
Using a different local variable allows to still accumulate the values,
while keeping away from the XCFLAGS from autoconf.mk.
Since the introduction of the STL wrappers, they have included
mozalloc.h, and multiple times, we've hit header reentrancy problems,
and worked around them as best as we could.
Taking a step back, all mozalloc.h does is:
- declare moz_* allocator functions.
- define inline implementations of various operator new/delete variants.
The first only requires the functions to be declared before they are used,
so mozalloc.h only needs to be included before anything that would use
those functions.
The second doesn't actually require a specific order, as long as the
declaration for those functions comes before their use, and they are
either declared in <new> or implicitly by the C++ compiler.
So all in all, it doesn't matter that mozalloc.h is included before the
wrapped STL headers. What matters is that it's included when STL headers
are included. So arrange things such that mozalloc.h is included after
the first wrapped STL header is fully preprocessed (and all its includes
have been included).
It turns out that, since we're including <new> before setting
_GLIBCXX_DEBUG, the debug parts of c++config.h are not activated, and
that has an impact of how much of the debug features of the STL are
activated.
In contrast, the upcoming changes to the STL wrappers are avoiding the
include of <new> before _GLIBCXX_DEBUG is set, which in turn breaks the
build because, as we link things that use STL wrappers with things that
don't, they end up with a different state of STL debugging, and have
mismatching symbols.
This updates the nss build to require SSE2 instructions on win32.
By default nss builds with -arch:IA32 for maximum compatibility.
Firefox 49 dropped support for non-SSE2 platforms, so propagate
that to the nss external build. XCFLAGS come after the nss build's
default settings, and the last -arch switch will override the
previous ones.
Bump CLOBBER because we've had trouble with file removal permission
errors on integration builds.
MozReview-Commit-ID: 2lfDq0e0T7Y
Previously, this clobbered the XCFLAGS set by MOZ_FOLD_LIBS_FLAGS.
Combine them instead so we can pass multiple options through
this override mechanism.
This is a behaviour change building with --enable-llvm-hacks.
MozReview-Commit-ID: 4WP0asnc7Z6
Enable debug output from the rust compiler when we're doing so
for the C/C++ compilers.
MozReview-Commit-ID: K0iqlPZ1Thu
--HG--
extra : rebase_source : 21220c0b7eeaa9036346e87d2bd1d475a129920e
Key size enforcement for TLS certificates happens at two levels: PSM and NSS.
PSM enforces a minimum of 1024 bits. NSS enforces a minimum of 1023 bits by
default. The NSS error is not overridable, but the PSM error is. This change
allows users to connect to devices with small RSA keys (as little as 512 bits)
using the certificate error override functionality.
MozReview-Commit-ID: 2TZ8c4I3hXC
--HG--
extra : rebase_source : a9c550f15261c711e789a670c90c129c65802ff0
Our current build system support for Rust compiles any Rust crate into a
so-called staticlib, which is a static library (.a file) that includes
the Rust runtime. That staticlib is then linked into libxul. For
supporting multiple crates, this approach breaks down, as linking
multiple copies of the Rust runtime is going to fail.
For supporting multiple crates, the approach taken here is to compile
each crate into a so-called rlib, which is essentially a staticlib
without the Rust runtime linked in. The build system takes note of
every crate destined for linking with libxul (treating them like static
libraries generated from C/C++ files), and generates a super-crate,
whimsically named "rul", that is compiled as a staticlib (so as to
include the Rust runtime) and then linked into libxul. Thus only one
copy of the Rust runtime is included, and the Rust compiler can take
care of any inter-crate dependencies.
This patch currently only supports Rust code in shared libraries, not in
binaries.
