This relies on the fact that providing multiple --version-script
combines them all, so we effectively create a new symbol version
that has no global symbol, but hides as much std::* stuff as possible.
The added symbol script could use `extern "C++"` syntax and demangled
symbols but there is no guarantee the demangled symbols won't change.
Plus, it's not possible to match demangled symbols that have a return
type: they contain a space, and the only way to match that is to use
double quotes, which doesn't allow globs at the same time.
This version script trick happens to work with BFD ld, gold, and lld.
The downside is that when providing multiple --version-script's, ld
doesn't want any of them to have no version at all. So for the libraries
that do already have a version script (through SYMBOLS_FILE), we use a
version where there used to be none, using the library name as the
version. Practically speaking, this binds the libraries a little closer
than they used to be, kind of non-flat namespace on OSX (which is the
default there), meaning the dynamic linker will actively want to use
symbols from those libraries instead of a system library that might
happen to have the same symbol name.
--HG--
extra : rebase_source : 78adb64b90e75ebad203b8a647b305c9d7198d16
In the span of one week, both gmplib.org and multiprecision.org,
respective home of gmp and mpc have gone down. The latter is still down.
It turns out that all versions of gmp and mpfr we need are mirrored on
ftp.gnu.org, so we can just use that instead. For mpc, versions > 1.0
are on ftp.gnu.org, but not earlier versions.
The one mpc version <= 1.0 we do need is 0.8.2, and a copy of the exact
same archive, as per its sha256, which we're already checking per the
gcc build scripts, can be found on snapshot.debian.org. We lose gpg
validation on the way, but since we're already checking the sha256,
that's a fine tradeoff.
At least this unblocks changes to toolchains until multiprecision.org
comes back online.
--HG--
extra : rebase_source : f2bc67f8757655d99bfd9735b80d7205f7bfe47b
Can be used:
ac_add_options --enable-linker=lld-7
or
ac_add_options --enable-linker=lld
MozReview-Commit-ID: GfDevGeooU4
--HG--
extra : rebase_source : ee2aad5f8f721a6fe5840affde6b29a3b940fb91
The python3-minimal package provides /usr/bin/python3 on Debian.
This commit installs this package so a `python3` executable is
provided.
This required backporting the package to wheezy. The final patch
is trivial. But I wasted a bit of time figuring out why `mk-build-deps`
wasn't working. It would no-op and exit 0 and then the build would
complain about missing dependencies!
glandium's theory is that the ":any" multiarch support on wheezy
isn't complete. Removing ":any" seems to make things "just work."
MozReview-Commit-ID: FBicpK4SmkQ
--HG--
extra : rebase_source : a28ce731024e8ed6a43fb30e2ed57da2abb50d0f
This option does nothing if it's provided, and things will probably
break in some most peculiar manner if somebody uses --without-pthreads.
Given that neither outcome is useful, we should remove the option.
It's the *compile*SdkVersion that needs to match the installed Android SDK plat-
form in order to be able to build an app, whereas the *target*SdkVersion is
merely a compatibility flag.
Since the received wisdom is that targetSdkVersion should be <= compileSdk-
Version and Android Studio is also showing a warning to that effect if you
modify the build.gradle of a small sample app accordingly, I've also added a
corresponding configure check of our own to enforce this.
MozReview-Commit-ID: F2RZemChFrm
--HG--
extra : rebase_source : cf4f6256baa4446d673b94d97f9497f93d7917ff
This serves two purposes:
1) It makes web-platform-tests pref downloading/handling a little more robust. When
run externally, it now downloads the entire testing/profiles directory. When loading
prefs it will look for both prefs_general.js (to support older versions of Firefox)
and profiles.json (for support moving forward).
This way we can add/remove/rename pref files under these directories without needing
to worry about breaking upstream wpt.
2) It provides developers an overview of which harnesses are using which base profiles.
Instead of hunting through test harness code to find this information, they can glance
at profiles.json.
MozReview-Commit-ID: AMzdnD8aGA2
--HG--
extra : rebase_source : 6fa0a802680417e49fcef99f3d03de7458a8fcba
svn revert requires a path, and does not take a revision. This isn't an
issue on build machines because we do a fresh checkout every time.
But if you're trying to run build-clang locally, with existing checkouts,
it will:
1) successfully svn update
2) run svn revert, saying "Skipped <rev>"
(except you don't see it because of -q)
3) svn revert returns a successfull eror code
4) patch fails because the file was never reverted and it attempts
to re-apply the patch
Also I think the revert command needs to come first.
MozReview-Commit-ID: 4OfrJNZwJNU
--HG--
extra : rebase_source : b3474e8048b3110f3f5948c3351923c02735ca4d
This moves testing/profiles/prefs_general.js to
testing/profiles/common/user.js. It also adds an 'extensions' folder to the
common profile. Dropping extension files here will get them installed in all
test harnesses (useful for testing on try).
The idea is that all test harnesses will eventually use this 'common' profile.
We'll also create some new per harness profiles, e.g testing/profiles/mochitest
and testing/profiles/reftest. This way there will be a single location
developers can go to set preferences, both for a specific harness, and across
all harnesses.
MozReview-Commit-ID: 8sqBqLiypgU
--HG--
rename : testing/profiles/prefs_general.js => testing/profiles/common/user.js
extra : rebase_source : 72a4a4b691e93c77479c7e70647b0ca373862c51
OOM rust crashes are currently not identified as such in crash reports
because rust libstd handles the OOMs and panics itself.
There are unstable ways to hook into this, which unfortunately are under
active changes in rust 1.27, but we're currently on 1.24 and 1.27 is not
released yet. The APIs didn't change between 1.24 and 1.26, so it's
fine-ish to use them as long as we limit their use to those versions.
As long as the Firefox versions we ship (as opposed to downstream) use
the "right" version of rust, we're good to go.
The APIs are in their phase of stabilization, so there shouldn't be too
many variants of the code to support.
--HG--
extra : rebase_source : 08a85aa102b24380b1f6764effffcc909ef3191b
This commit also removes "DEFAULT_APP", which is unused.
MozReview-Commit-ID: 5YYaC5LJqUn
--HG--
extra : rebase_source : 45f0f8f11698890fae0dcca71174f88dbdb412c8
Since it is run with `mach python`, it uses the environment defined by
`build/virtualenv_packages.txt`. Thus, we don't need to create a separate
virtualenv.
Differential Revision: https://phabricator.services.mozilla.com/D1015
--HG--
extra : rebase_source : 023095f82d7219a10dffb3579276c5285db37cfc
extra : source : a2999a5b9b7aa08a7c5c2ba6384724853d14b9c5
We previously did not require Python 3.5+ everywhere because we failed
to detect Python 3.5 on Windows in CI. That's because CI isn't using
start-shell.bat and it hasn't yet updated PATH to include
%MOZILLABUILD%\python3.
We shouldn't need to teach CI to have PATH contain everything in
MozillaBuild. This commit teaches moz.configure to automatically use
MozillaBuild's Python 3 if we're running in MozillaBuild.
Since we can now detect Python 3 everywhere in CI, we make Python 3.5+
required on all build configurations.
MozReview-Commit-ID: BwgWGeYMyPM
--HG--
extra : rebase_source : b52f604b01c73b0493b142f3f71aa26c99a42b91
for: taskgraph: Make update tasks support esr60
MozReview-Commit-ID: GUmAq3sBXGB
--HG--
extra : rebase_source : 0eaeb17809fede07f6b9fc4ee5d856d0078f83be
But only if we are:
a) not running in CI
b) running in CI on Linux
We will ideally make the requirement global. But Python 3.5 is not
yet available in CI on macOS. And we're not finding the MozillaBuild
copy in configure.
This was previously announced in November at
https://groups.google.com/d/msg/mozilla.dev.platform/rJrPh1QYXrQ/hqRrQsJ_BgAJ.
MozReview-Commit-ID: IyPCAcL3gop
--HG--
extra : rebase_source : f9e3db043a1ce9c1a903c943663f22245febf101
checksums.py is now run after upload.py, as part of the "upload" make
target.
As part of the refactor, checksums.py now takes as arguments a list of
directories containing files to checksum. It will recursively checksum
all files in listed directories.
This means we no longer have to pass an explicit list of files into
checksums.py. Instead, we can pass the artifact directory and
automatically checksum everything within. This will allow us to
generate files directly into the artifact directory instead of
having to run upload.py to copy files there.
MozReview-Commit-ID: 6ntnXU2Pp0E
--HG--
extra : rebase_source : 7e019b366f14b3692ec702ff331a1e0306dc3805
.write() is the preferred mechanism to write to a file object.
MozReview-Commit-ID: 1uhNeFayoxV
--HG--
extra : rebase_source : 5244e5548cefb8ebf98cb2415ab139e96e967433
This makes the logic in process_files() simpler.
MozReview-Commit-ID: KdphRJZLinx
--HG--
extra : rebase_source : 14a89fc9ba85d1dd4c2d2d18d0383552bb2d8e69
Garbage in garbage out. Let's make this code simpler.
MozReview-Commit-ID: Gv0ZcMacyOX
--HG--
extra : rebase_source : 2e8131bc1926b6ad7f186d0778fe4b339c6ba834
A missing or unimportable hashlib is only possible on very old or very
busted Pythons. Remove code for conditionally handling a failure to
import it.
MozReview-Commit-ID: EXVlmttcwUa
--HG--
extra : rebase_source : 30177c86dc5e92dd3234177f383681f9aa70682e
The argument is never used in the local file copying function. So let's
nuke the argument.
MozReview-Commit-ID: JeU4LaVvGD7
--HG--
extra : rebase_source : 0e305c5bff0e3871fd11a554d75e7f53ceea4bdd
This was only used for the remote server case. That code was recently
deleted.
MozReview-Commit-ID: 7usqWZ7CuBR
--HG--
extra : rebase_source : f27b37391802a2980feffa5d88c92228d137824f
extra : source : 46b8a00288c8d7b88fd9b7aee20e88ddfd96d57b
With the transition to Taskcluster, "uploads" are artifacts in a local
directory. So we don't need to support uploading to a remote server
using SCP.
This commit removes all the code to support uploading to a remote
server.
And since property files were only written out for the remote case, all
that code can be deleted as well.
Since UPLOAD_HOST no longer means anything, we no longer set it in
mozharness configs.
MozReview-Commit-ID: 66gkM8erkGk
--HG--
extra : rebase_source : ee85bb927cfb98e1ca383ab2591febfc1f0ce5cd
We add a minimal Python script to run a process and prefix all its
output with a string. We change the automation tiers to evaluate all
make targets using this script.
MozReview-Commit-ID: 79g5KUd5ked
--HG--
extra : rebase_source : 63388a71b51e5abc05ca8bd48e180af72bf799e6
The argument is never used in the local file copying function. So let's
nuke the argument.
MozReview-Commit-ID: JeU4LaVvGD7
--HG--
extra : rebase_source : a898814f4084288200928f062fbb06ffbbae60bd
This was only used for the remote server case. That code was recently
deleted.
MozReview-Commit-ID: 7usqWZ7CuBR
--HG--
extra : rebase_source : 39c33057aab6773f8f85b1294e4965965954d9e6
With the transition to Taskcluster, "uploads" are artifacts in a local
directory. So we don't need to support uploading to a remote server
using SCP.
This commit removes all the code to support uploading to a remote
server.
And since property files were only written out for the remote case, all
that code can be deleted as well.
Since UPLOAD_HOST no longer means anything, we no longer set it in
mozharness configs.
MozReview-Commit-ID: 66gkM8erkGk
--HG--
extra : rebase_source : 15143a18598370eeaaa98f8f0ac8458d758db51f
The previous commit moved creating installers to be side effect of creating
packages. This makes the installer step not actually do anything. So remove the
step from automation.
Differential Revision: https://phabricator.services.mozilla.com/D864
--HG--
extra : rebase_source : 75b67a6e57031ae189dafe1d9854e4105aa22621
extra : source : fcb756834abbdbe0ae6e59a8cfdf39024f50a226
The previous commit moved creating installers to be side effect of creating
packages. This makes the installer step not actually do anything. So remove the
step from automation.
Differential Revision: https://phabricator.services.mozilla.com/D864
--HG--
extra : rebase_source : 174a366890da295634ef8971d0608ea60979f110
extra : histedit_source : 06fdd0e2ccb93f061ba5a40c2a4137eed9898916
(This also fixes Bug 879740 and Bug 1204543.)
build/pgo/certs contains an NSS database set that has a bunch of hand-generated
certificates, and many of these hand-generated certificates are specifically
depended upon for a variety of unit tests. This patch changes all of these to
use the "pycert.py" and "pykey.py" utilities that produce deterministic keys
and certificates.
The naming convention here is new, and defined in the README. It is based on
the mochitest runtest.py naming convention that imports .ca and .client
PEM-encoded certificates.
Unfortunately, the updates to build/pgo/genpgocert.py to generate these files
depends on OpenSSL in order to produce PKCS12 archives for pk11tool to import
into NSS. This could be done with pure-NSS tooling, but it'd require some new
command line functionality, which is out-of-scope for this change.
Note that build/pgo/genpgocert.py no longer takes arguments when run. It's not
run automatically anywhere that I can see, but could (reasonably) be, now.
Differential Revision: https://phabricator.services.mozilla.com/D971
--HG--
extra : amend_source : bc389b9b0a807a4889feb14db439daa28635dfe9
The existing suppression tries to be specific about the callstack that
arrives at the function, but that breaks when we rejigger the machinery
up the callstack. In practice, the existing suppressions cover most of
the ways we would arrive at selector parsing, and so I think the
specificity here is more trouble than it's worth.
MozReview-Commit-ID: 2k52xq64SQX
This makes the changes necessary to use TestRunnerActivity when geckoview
is installed and requested, but we do not yet attempt to run any such
test tasks in automation.
And adapt the build-gcc.sh script for the changes to
contrib/download_prerequisites.
--HG--
rename : taskcluster/scripts/misc/build-gcc-6-linux.sh => taskcluster/scripts/misc/build-gcc-7-linux.sh
extra : rebase_source : b1d785777b8c141c0eb0f52a73734abd2db21b94
This forces the linker ot use libatomic with clang on x86 (not only Android)
and forwards the intent to use libatomic to the shell's moz.build.
--HG--
extra : rebase_source : 0c803a3e11efcad3f17a462c2d38e85ec6cb556a
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 65bac47c2cd1a20b3c675a01b44a25a1d2d3ab7a
Debian 7 ships Python 3.2 by default. That's too old for our
upcoming build requirement of Python 3.5.
This commit adds a Python 3.5 package for wheezy that backports
the Python 3.5 from a much later Debian version.
The patch was inspired by the existing patch for Python 2.7.
However, it needed additional work. The changes and reasons
should all be documented in the changelog file as part of the
package diff we apply.
I'm a bit disappointed we had to disable PGO. But it was
reliably segfaulting during the build. I didn't feel like going
down that rabbit hole.
MozReview-Commit-ID: ABpHW1KYFQP
--HG--
extra : rebase_source : 02dbd13236fe741cb33f07c803218fda339c214e
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 6f7d4fd1d6cdea2c14866705a2dc972eb5f43382
This patch adds suppressions as needed on automation, for Servo-in-Gecko as
compiled by rustc 1.25. It appears there are only three false error sites
fun:*style*values*specified*color*Color*style*parser*Parse*parse*
fun:*selectors*parser*SelectorList*Impl*parse*
fun:*style*properties*shorthands*
but there are a number of different paths leading to them, especially the
first, hence the use of 17 suppressions in total, so as to remain specific.
Following some investigation of the machine code involved, I think these are
all Valgrind/Memcheck false positives, unfortunately, and probably to do
with (legitimate) operand swapping in && or || expressions by rustc+LLVM.
MozReview-Commit-ID: EpDmb4PEyoy
The check for whether an implicit constructor is in a third-party
directory currently has a homegrown list of directories to ignore.
Let's move this over to the (more complete!) list of third-party
directories maintained elsewhere.
In nsFrame::ComputeSize and nsFrame::ComputeSizeWithIntrinsicDimensions, the
following expressions
isFlexItem && usingFlexBasisForISize
isFlexItem && !usingFlexBasisForISize
are sometimes compiled by recent gcc/clang in the opposite order, viz
[!]usingFlexBasisForISize && isFlexItem. In this case the transformation is
correct as can be seen by analysing code earlier in these functions.
Unfortunately this causes Valgrind/Memcheck to report a branch on undefined
data which, in this case, is a false positive.
A simple fix is simply to initialise usingFlexBasisForISize to false at its
declaration point.
--HG--
extra : rebase_source : 39877e4ea8ec678288e6b49af120445c96ef8c0a
It's much easier to find that way, specially for functions with tons of
argument.
MozReview-Commit-ID: i3PMjDOcH7
--HG--
extra : rebase_source : 2c79f0b4eb5c6022c3896ded3bd26ceda524ce5a