The current setup for bindgen relies on either finding clang/libclang
from the output of llvm-config, or from the paths given via the
configure flags --with-clang-path/--with-libclang-path.
One _very_ common problem is that the llvm-config we end up using does
not correspond to the clang used for compilation, which has some
undesirable side effect, like failing to build.
So instead of relying on llvm-config, we do the following:
- when the compiler is clang, we just use that
- when the compiler is clang-cl, we use clang from the same directory
- otherwise, we either try to find clang in PATH, or rely on
--with-clang-path.
Once clang is found, we try to deduce the location of the corresponding
libclang via the output of `clang -print-search-dirs`, or rely on
--with-libclang-path.
Differential Revision: https://phabricator.services.mozilla.com/D33241
--HG--
extra : moz-landing-system : lando
The 3-tier PGO builds used a separate mozconfig called 'profile-use' for
the final tier. This created a problem when it rode to beta, since the
same mozconfig was used for all trees, which meant we ended up with
nightly branding on beta builds.
With the PGO-enabling logic in common mozconfigs, we can enable it by
setting the MOZ_PGO_PROFILE_USE environment variable from the task
definition. All of the final-tier PGO builds now use the nightly, beta,
etc mozconfigs like before, so branding should be intact.
Differential Revision: https://phabricator.services.mozilla.com/D33172
--HG--
extra : moz-landing-system : lando
We were never adjusting `last` in this loop, so we were computing the
wrong addresses for all sections beyond the first. Which in turn meant
that we would compute the wrong size for the section data we needed to
allocate.
Differential Revision: https://phabricator.services.mozilla.com/D28195
--HG--
extra : moz-landing-system : lando
We were allocating ElfSection's data with `new[]` and modifying it with
`realloc` in some places, which causes allocator mismatches.
Consistently manage the data with `malloc`, `realloc`, and `free` instead.
Differential Revision: https://phabricator.services.mozilla.com/D27327
--HG--
extra : moz-landing-system : lando
When cross-building with clang, we use `--target` with a target that is
derived from the configure target, with the vendor removed. So for
`configure --target=aarch64-unknown-linux-gnu`, we use
`clang --target=aarch64-linux-gnu`.
Then, clang itself looks for tools as `$target-$tool` first, then
`$tool`, which means for the assembler, it's looking for
`aarch64-linux-gnu-as` before `as`, but not
`aarch64-unknown-linux-gnu-as`.
Building GNU as with `--target=aarch64-unknown-linux-gnu` creates the
`aarch64-unknown-linux-gnu-as`, but we really want `aarch64-linux-gnu`,
so we adjust the target in the binutils build script.
Differential Revision: https://phabricator.services.mozilla.com/D25684
--HG--
extra : moz-landing-system : lando
Last time we updated the requirements was in bug 1278456, after we
switched to GTK+3.
While it might be worth checking what would be a reasonable requirement,
the immediate problem is that updating ANGLE hits a snag with a
libstdc++ 4.7 symbol, and the only main distro release that bumping to
that version would make us not support anymore is Ubuntu 12.04 LTS,
EOLed 2 years ago (April 2017).
Bumping to some even newer version would need more consideration.
Desupporting Ubuntu 12.04 LTS at this point is almost a no-brainer.
Differential Revision: https://phabricator.services.mozilla.com/D23979
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
These toolchain tasks are the last ones using the historical
download-tools script from build/unix/build-gcc, which invokes gpg to
validate the downloaded tarballs. The consequence is that gpg-agent is
spawned and stays running, preventing a cleanup script from doing its
job, making the tasks fail.
Fetches are the new way to download sources, and can also do gpg
validation without those caveats.
The download-tools.sh script can then be removed as it's not used
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D22682
--HG--
extra : moz-landing-system : lando
These are copies of the corresponding gcc-based base toolchain tasks,
with FORCE_GCC and the gcc dependency removed.
We also tweak things a little for those builds to actually end up green.
Differential Revision: https://phabricator.services.mozilla.com/D18903
--HG--
extra : moz-landing-system : lando
These are copies of the corresponding gcc-based base toolchain tasks,
with FORCE_GCC and the gcc dependency removed.
We also tweak things a little for those builds to actually end up green.
Differential Revision: https://phabricator.services.mozilla.com/D18903
--HG--
extra : moz-landing-system : lando
In bug 1470701, we added a dummy global variable so that it ends up in
the bss section, making it large enough for two pointers. Unfortunately,
in some cases, the symbol is eliminated by the linker because it is
unused. So we try to ensure it stays there.
Differential Revision: https://phabricator.services.mozilla.com/D11257
--HG--
extra : moz-landing-system : lando
This is some sort of followup to bug 1423813, providing a minimalistic
way to undo elfhack when the elfhack sections are in separate segments,
which has been the case since bug 1385783 but didn't cause problems
on Android builds until bug 1423822.
Depends on D9622
Differential Revision: https://phabricator.services.mozilla.com/D9623
--HG--
extra : moz-landing-system : lando
This effectively backs out bug 822584, which worked around a similar
problem to what we are facing with Android xpcshell, being that the
crash reporter doesn't handle the address space "fragmentation" induced
by elfhack. The work around worked, at the expense of some added
complexity.
It was used for B2G only, and has effectively been unused since B2G was
retired.
Differential Revision: https://phabricator.services.mozilla.com/D9622
--HG--
extra : moz-landing-system : lando
We need to sign parts of the contents of the archives, so the mar's that we
ship get built as part of the repackage task. Thus, there is no reason to also
create and upload as part of the build, just to throw them away.
Differential Revision: https://phabricator.services.mozilla.com/D6213
--HG--
extra : moz-landing-system : lando
When checking whether the new relocations sizes are going to be a win, we
need to account for the fact that there are non-elfhacked relocation
remaining.
Differential Revision: https://phabricator.services.mozilla.com/D5837
--HG--
extra : moz-landing-system : lando
Now that Linux PGO builds also do LTO and all the Linux builds use
clang, there's not much use for separate LTO builds.
Differential Revision: https://phabricator.services.mozilla.com/D5632
Last attempt, a few years ago, blatantly failed because nautilus (the
GNOME file manager) can't start PIE executables, which look like shared
libraries, and that it thus considers not being executables.
Downstreams don't actually have the problem, because users won't be
launching Firefox from a file manager, but for mozilla.org builds, it is
a problem because users would download, then extract, and then likely
try to run the Firefox executable from a file manager.
So for mozilla.org builds, we still need to find a way around the
nautilus problem.
A .desktop file could be a solution, but .desktop files have not
actually been designed for this use case, which leads to:
- having to use an awful one-liner shell wrapper to derive the path
to the executable from that of the .desktop file,
- not even being able to associate an icon,
- the .desktop file not being copiable to a location where .desktop
files would normally go, because it would then fail to find the
executable.
Another possibility is to go back to using a shell wrapper, but that's
not entirely appealing.
What we chose here is similar, where we have a small `firefox` wrapper
that launches the real `firefox-bin` (which is still leftover from those
old times where we had a shell wrapper, for reasons).
The small `firefox` wrapper is a minimalist C executable that just
finds the path to the `firefox-bin` executable and executes it with the
same args it was called with. The wrapper is only enabled when the
MOZ_NO_PIE_COMPAT environment variable is set, which we only take into
account on Linux. The variable is only really meant to be used for
mozilla.org builds, for the nautilus problem. Downstreams will just pick
the default, which is changed to build PIE.
On other platforms, PIE was already enabled by default, so we just
remove the --enable-pie configure flag.
Differential Revision: https://phabricator.services.mozilla.com/D5109
Bug 1487330 made mozconfig.asan use mozconfig.linux, but while that
worked out fine, it turns out that we do have mac builds using
e.g. mozconfig.asan, and that those can break when doing linux-specific
changes to mozconfig.linux.
--HG--
rename : build/unix/mozconfig.linux => build/unix/mozconfig.unix
With patches from other bugs in place to use the right C compiler and cflags,
we can enable geckodriver on cross-compiles for macOS.
MozReview-Commit-ID: 5wqBiA6UCf
All the Linux builds using GCC uses the binutils bundled with GCC. This
gives us some leeway to update the binutils used for clang builds (using
the binutils toolchain as of bug 1486998) separately.
Since we only ship builds using GCC, we're more free to upgrade
binutils for clang builds, without worrying about the next merge.
This upgrades to the last released version of binutils, and applies the
patch from https://sourceware.org/bugzilla/show_bug.cgi?id=23591 on top,
so that asan fuzzing builds don't fail.
The GPG key used to sign the upstream tarball is unfortunately not
connected to the web of trust. I verified the contents matched what's in
the Debian archive (which has a different tarball, because some files
are removed/modified in Debian for license reasons ; there were no
differences besides those).
Differential Revision: https://phabricator.services.mozilla.com/D4748
--HG--
extra : moz-landing-system : lando
Those mozconfigs do things in common that are already in
mozconfig.linux. Let's just use that.
This will make the build have the binutils toolchain in PATH rather than
passing it to CC/CXX, which is better because it also makes the build
use tools such as ar, ranlib, objcopy from the binutils toolchain,
rather than the old system ones.
Differential Revision: https://phabricator.services.mozilla.com/D4649
Those mozconfigs do things in common that are already in
mozconfig.linux. Let's just use that.
This will make the build have the binutils toolchain in PATH rather than
passing it to CC/CXX, which is better because it also makes the build
use tools such as ar, ranlib, objcopy from the binutils toolchain,
rather than the old system ones.
Differential Revision: https://phabricator.services.mozilla.com/D4649
The x86 linux builds originally were performed in x86 build environment.
That was a long time ago. Since then, they moved to x86-64 hosts with
x86 headers and libraries. But for reasons that might have to do with
the build system not really supporting cross-compilation nicely back
then, the build is still explicitly passing both --host and --target,
making those builds non-cross builds.
Since the toolchains used to build are for x86-64, the fact that --host
is for x86 actually prevents enabling the clang plugin, so we need to
turn these builds in actual cross builds if we want to enable the clang
plugin.
The x86 linux builds originally were performed in x86 build environment.
That was a long time ago. Since then, they moved to x86-64 hosts with
x86 headers and libraries. But for reasons that might have to do with
the build system not really supporting cross-compilation nicely back
then, the build is still explicitly passing both --host and --target,
making those builds non-cross builds.
Since the toolchains used to build are for x86-64, the fact that --host
is for x86 actually prevents enabling the clang plugin, so we need to
turn these builds in actual cross builds if we want to enable the clang
plugin.
Mike Hommey
Mike Shal
Sylvestre Ledru
Nathan Froyd
Nathan Froyd
Gurzau Raul
shindli
David Major
Ehsan Akhgari
Tom Prince
Chris Peterson
Ted Mielczarek
Sebastian Hengst
Hiroyuki Ikezoe
Dorel Luca