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.
- Merge in test changes from Bug 1255784.
- Remove the unnecessary mutex
- Stop doing direct memory work in NSS Token
- Clean up direct memory work in ContentParent
- In order to store persistent crypto parameters, the NSSToken had to move
onto the main thread and be interfaced with via IDL/IPDL.
- Support Register/Sign via NSS using a long-lived secret key
- Rename the softtoken/usbtoken "enable" prefs, because of hierarchy issues
with the WebIDL Pref shadowing.
- Also orders the includes on nsNSSModule.cpp
- Attestation Certificates are in Part 2.
Updates per keeler review comments:
- Use //-style comments everywhere
- Refactor the PrivateKeyFromKeyHandle method
- Rename the logging and fix extraneous NS_WARN_IF/logging combinations
- Other updates from review
April 11-12:
- Correct usage of the "usageCount" flag for PK11_UnwrapPrivKey
- Rebase up to latest
April 15:
- Rebase to latest
MozReview-Commit-ID: 6T8jNmwFvHJ
--HG--
extra : transplant_source : w%26%CES%2Cu%04%3EAl%04%2Cb%E2v%C9%08%3A%CC%F4
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. The handling for the rul crate is placed in the common
backend, with a special hook for derived backends to handle shared
library objects.
In contrast to the GNU AS manual, the syntax for the .section directive
uses '%progbits' instead of '@progbits'; at least on ARM. Looking at the
ICU tools and the generated files confirms this.
Multiple people have complained that the build output of printing the
source files being built adds little value. I agree. The extra output
doesn't give really helpful progress info because sources can be built
in non-deterministic order. Furthermore, the extra output hides useful
output like compiler warnings.
This patch makes the default build system output even less verbose. We
no longer print the individual source targets when they are built. We do
still print the targets for binaries, so some sense of progress can be
inferred.
If people like verbosity, they can export the undocumented
BUILD_VERBOSE_LOG environment variable can be set to restore the old
behavior.
MozReview-Commit-ID: KeaeJJkjPJn
--HG--
extra : rebase_source : a90b4b82eeef48d9bd896b5c12907ce05a650d4d
Also fixes bug 926980 - load ICU data from an archive file.
Stop invoking ICU's autoconf build system. Instead, have hand-authored
moz.build files under config/external/icu to build what we need. In addition,
we'll commit a pre-built copy of the ICU data file (currently icudt56l.dat)
under config/external/icu/data to avoid having to build ICU host tools to
generate it. config/external/icu/data also contains some assembly files
which can generate an object file containing the ICU data file contents
so that the JS shell (or standalone JS builds) can be linked directly to
the data without having to deal with the external data file. This requires
yasm or GNU as.
Various bits of packaging have been updated to account for the ICU data file.
XPCOM initialization now sets the ICU data directory so ICU can locate its
data file.
The update-icu.sh script has been modified to read the list of C/C++ source
files out of the ICU Makefiles and update `sources.mozbuild` files under
config/external/icu, as well as build a local copy of ICU using its
autoconf build system to generate the ICU data file to be committed in-tree.
MozReview-Commit-ID: 8Pfkzqt6S1W
--HG--
extra : rebase_source : 31426cddddb5543e0191059ba2f2eb069abe7727
Gradle produces signed, unaligned APK files. We expect unsigned,
unaligned APK files. This change discards any existing signature,
turning a signed, unaligned APK into an unsigned, unaligned APK.
Sadly |zip -q| does not silence a warning message about "nothing to
do" so we pipe to /dev/null.
MozReview-Commit-ID: DnSGJCvHsym
--HG--
extra : rebase_source : ee7884847767c0a075e3cfd404ba695d07f47e93
extra : histedit_source : 6aaa07eac03d69668f8556b84d1c1bae51c8ea22
It's an opt-in flag that allows to display where the build is in
terminal window titles. The fact that it's opt-in and likely unknown
makes it very low-value, and the fact that it was added in an era where
builds were not very well parallelized made it have a meaning, but now
that builds are parallelized, its meaningfulness is diminished.
Let's just remove it.
When a built-in root certificate has its trust changed from the default value,
the platform has to essentially create a copy of it in the read/write
certificate database with the new trust settings. At that point, the desired
behavior is that the platform still considers that certificate a built-in root.
Before this patch, this would indeed happen for the duration of that run of the
platform, but as soon as it restarted, the certificate in question would only
appear to be from the read/write database, and thus was not considered a
built-in root. This patch changes the test of built-in-ness to explicitly
search the built-in certificate slot for the certificate in question. If found,
it is considered a built-in root.
MozReview-Commit-ID: HCtZpPQVEGZ
--HG--
extra : rebase_source : 759e9c5a7bb14f14a77e62eae2ba40c085f04ccd
They were behind WANT_MOZILLA_CONFIG_OS_VERSION, which nothing has been
setting ever since the ifdef was changed from
MOZILLA_CONFIG_IGNORE_OS_VERSION... in 2000. Not that anything was
setting MOZILLA_CONFIG_IGNORE_OS_VERSION either... well, at least not in
Gecko.
Our STL wrappers do various different things, one of which is including
mozalloc.h for infallible operator new. mozalloc.h includes stdlib.h,
which, in libstdc++ >= 6 is now itself a wrapper around cstdlib, which
circles back to our STL wrapper.
But of the things our STL wrappers do, including mozalloc.h is not one
that is necessary for cstdlib. So skip including mozalloc.h in our
cstdlib wrapper.
Additionally, some C++ sources (in media/mtransport) are including
headers in an extern "C" block, which end up including stdlib.h, which
ends up including cstdlib because really, this is all C++, and our
wrapper pre-includes <new> for mozalloc.h, which fails because templates
don't work inside extern "C". So, don't pre-include <new> when we're not
including mozalloc.h.
When a built-in root certificate has its trust changed from the default value,
the platform has to essentially create a copy of it in the read/write
certificate database with the new trust settings. At that point, the desired
behavior is that the platform still considers that certificate a built-in root.
Before this patch, this would indeed happen for the duration of that run of the
platform, but as soon as it restarted, the certificate in question would only
appear to be from the read/write database, and thus was not considered a
built-in root. This patch changes the test of built-in-ness to explicitly
search the built-in certificate slot for the certificate in question. If found,
it is considered a built-in root.
MozReview-Commit-ID: HCtZpPQVEGZ
--HG--
extra : rebase_source : 898ef37459723f1d8479cfdc58658ccb00e782a9
We can just generate xpidllex.py/xpidlyacc.py in the current directory
rather than one directory higher, and specify this directory as an
include path to xpidl-process.py
MozReview-Commit-ID: KLoGjudc4Y8
--HG--
extra : rebase_source : 8dda268c6490cdfb8b896de9da5b789208584193
Nothing uses this variable. blame suggests that it was used for HP-UX
once upon a time. The companion variable, MOZ_POST_PROGRAM_COMMAND, is
only used by HP-UX, but as we're not wholesale removing HP-UX
support (yet), we should leave MOZ_POST_PROGRAM_COMMAND alone.
One can run individual tests with python testfile.py Class.method. But
the output for tests only shows the method so looking at a test output
is not enough to tell how to run one particular test. Moreover, there
are many cases where a test file contains multiple classes, and we fail
to identify the difference between those classes.
Python's unittest has decorators to mark tests as skipped or expecting
to fail. Mozunit runner fails to print anything for them.
While here, somehow unify the output for TEST-UNEXPECTED-FAIL.
This leaves known failures silent about the failure. It would be better
to only show them with a flag, like -v, and to leave it to a followup.
Python's unittest separates errors and failures, where the former is
uncaught exceptions and the latter uncaught assertions. We were only
printing the former, making the mozunit runner output useless to debug
failures due to assertions in the code being tested.
I would usually edit the test to temporarily switch to unittest.main().
Enough is enough, handle failures properly.
At the same time, instead of printing all the errors one after the other
at the end, print them right after the TEST-UNEXPECTED-FAIL message.
The behavior is not entirely idempotent (most notably for
buildconfig.html), but this can be improved later if necessary.
It is idempotent where it matters.
This allows to get rid of config/makefiles/rcs.mk and its uses.
ALLOW_COMPILERS_WARNINGS is set in moz.build files, which end up producing backend.mk files, which are loaded as part of config/rules.mk.
--HG--
extra : rebase_source : 75643ff0a30be733216d5572668a52ab365d7c59
Mike Hommey
Dustin J. Mitchell
Wes Kocher
ffxbld
Makoto Kato
David Keeler
Ralph Giles
Martin Thomson
Nathan Froyd
Nathan Froyd
Mike Shal
Thomas Klausner
Lee Salzman
Nathan Froyd
J.C. Jones
Chris Manchester
Kai Engert
Sebastian Hengst
Thomas Zimmermann
Gregory Szorc
Tooru Fujisawa
Ted Mielczarek
Nick Alexander
Karl Tomlinson
Terrence Cole
Myk Melez
Ms2ger
Ehsan Akhgari
Masatoshi Kimura
Jan de Mooij
Landry Breuil
Luke Wagner
Steve Fink