rust-bindgen will make an enum variant for the first definition it encounters,
and then define duplicates as constants outside of the enum definition. This has
the unfortunate effect of making AsmJSCache_MIN an enum variant and
AsmJSCache_Success the constant definition outside of the enum in the case of
the AsmJSCacheResult enumeration. This commit rectifies that.
This upstreams the following commit from servo/mozjs:
50f47cf Bind AsmJSCache_Success rather than AsmJSCache_MIN
With more recent version of ASAN, the updater program shows multiple
leaks, for different reasons.
One is that the updater code heavily relies on pointers into a large
buffer, with exceptions, making things difficult to avoid leaks of those
exceptions. At least it requires more effort than I'm willing to put for
the sake of upgrading the compiler we use for ASAN.
Another is that the leak suppressions are not currently used for
xpcshell tests, and some leaks attributed to libglib, that would
normally be suppressed, are not.
Moreover, even if the suppressions were used, it looks like some are not
rooted to already suppressed system libraries, and would require
investigation. Ideally, we'd have debug symbols installed for the system
libraries and would have full stack traces, but we don't, so this makes
the whole process harder than necessary.
All in all, the updater is a separate short-lived program, and until we
can address all the problems above, we can just ignore memory leaks in
it (which aren't new anyways and are ignored by not being detected by
the ASAN currently used on automation). We don't disable ASAN entirely,
though, only leak detection, and only for the updater program.
Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
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.
