We're currently building GCC with the system binutils, which, at the
moment, is whatever version is available on the CentOS 6 build
environments. With the imminent switch to Debian 7, that will be a
different version.
It turns out the GCC configure script does enable some features
depending on the binutils it's built with. For the most notable
differences it makes when going from Centos 6 to Debian, it enables
.init_array/.fini_array depending on the binutils version, and enables
the use of CFI advances depending on gas and objdump respectively
supporting and displaying DW_CFA_advance_loc.
But we're already building a fixed version of binutils (which happens to
be more recent than the one in both CentOS 6 and Debian 7), and we're
using that version when using GCC to build, so we can just as much use
the version we built to build GCC.
In order to avoid any changes to the resulting builds, we explicitly
turn off .init_array/.fini_array (which currently happens implicitly
when building on CentOS 6). This will ensure that there is not other
change to the builds due to this binutils version bump
(.init_array/.fini_array being enabled shifts everything in the
binaries, so it makes the whole diff full of noise)
mk_add_options has this kind of awkward feature where
mk_add_options VAR=value
would set VAR for the build through client.mk, but not when running
make -C objdir target. But
mk_add_options "export VAR=value"
does.
We might want to change that on the long run, but the side effects would
have to be calculated first.
OTOH, we have automation jobs that run compilations during `make check`
(e.g. rusttests), which is not invoked through client.mk. So they
currently don't get the same PATH as the build part, meaning that
they're using system binutils instead of the one from the GCC toolchain
package.
--HG--
extra : rebase_source : aab7f221243c486cf70c7b0c91b9313231050ed8
We no longer support Android/armv6 and we requires NEON for Android/arm, so
we can remove armv6 support for Android.
MozReview-Commit-ID: Hh17BTyE0wR
--HG--
extra : rebase_source : 57e043ecb1bb57a026c0b656b82768b899ddae78
I was able to reproduce the failure to apply llvm-dsymutil on the last
mozilla-central revision before debug info was temporarily disabled for
rust, and validated that the problem was gone in clang 4.
After some bisection, r289565 was identified as having fixed the
problem, which, reading the commit message, makes sense.
It was however not possible to simply cherry-pick, because of multiple
code changes between 3.9 and 4. However, apart from the volume of
conflicting changes, it was more or less straightforward to backport.
Interestingly, the patch for r313872 was relying on changes from
r289565, which is why it required a variant specifically for 3.9, but
now we can use the same patch as for other versions. Well, except
there's a small difference in the context, and build-clang.py doesn't
allow fuzz, so we manually edit the patch to remove that line from the
context.
--HG--
extra : rebase_source : de0ab262d401c37c0e9300b0ef7923a07c009d87
In bug 1426785, Gtk+3 build was moved to docker image creation time, and
at the same time, the removal of .la files was stripped, because it
seemed too broad to do that in /usr/local/lib*, and because I didn't
really remember why it was there in the first place.
I now do remember, and that's because libtool likes to add useless
dependencies on libraries just because direct dependencies transitively
depend on them. For example, this adds a dependency on libffi to
libpangocairo, which doesn't use it directly.
I also happens that /usr/local/lib* is empty at the moment we build
gtk3, so we can just do the cleanup there.
On its own, this change is useless, but:
- it restores the libraries in their state pre-bug 1426785,
- it helps reduce some differences when building on Debian (for bug
1399679), easing the comparison of those builds.
--HG--
extra : rebase_source : 3fa644d8ae5eb4ccac5940c7d3605201f589936d
I was able to reproduce the failure to apply llvm-dsymutil on the last
mozilla-central revision before debug info was temporarily disabled for
rust, and validated that the problem was gone in clang 4.
After some bisection, r289565 was identified as having fixed the
problem, which, reading the commit message, makes sense.
It was however not possible to simply cherry-pick, because of multiple
code changes between 3.9 and 4. However, apart from the volume of
conflicting changes, it was more or less straightforward to backport.
Interestingly, the patch for r313872 was relying on changes from
r289565, which is why it required a variant specifically for 3.9, but
now we can use the same patch as for other versions. Well, except
there's a small difference in the context, and build-clang.py doesn't
allow fuzz, so we manually edit the patch to remove that line from the
context.
--HG--
extra : rebase_source : cda077132ee499a8ffdc4c88a1160cfa5fd86a97
It now only does something trivial, which also happens to be a no-op
because it's the default. It does have a commented entry for possible
gtk+2 builds, but we're soon going to remove that possibility anyways in
bug 1278282.
--HG--
extra : rebase_source : 9ac927bb7bd8c057264c8f6f9ca5cbf79a839c4e
Now that build environment docker images have gtk+3 installed in
/usr/local, adjust mozconfigs to point pkg-config there, and remove
all the glue that was required to build using the tooltool package.
Also remove the --x-libraries=/usr/lib on 32-bits builds, which only
confuses the linker.
--HG--
extra : rebase_source : c7de7b3959a3c6b77ea202d9609c891b5b7ec442
Back when we started needing gtk+3 to build Firefox, we were using mock
to setup the build environment, and a tooltool package was the most
sensible way to handle this.
Fast forward to today, and we're close to moving the build environment
to Debian, which comes with gtk+3 packages. But in order to simplify
the various checks for the transition, it is desirable to stop using the
tooltool package. Which we can actually do in a reasonable way now that
we use docker images instead of mock, by building and installing gtk+3
in the build environment images.
So we modify the script that was producing the gtk+3 tooltool packages
such that it installs gtk+3 in the docker images, both 32 and 64 bits.
And invoke it when creating the desktop build environment docker images.
--HG--
extra : rebase_source : 75e987d6de7f3ae8a3d9b478fc173e191d28aace
ccache is not beneficial on taskcluster, don't try to use it when
sccache is not enabled for some reason.
--HG--
extra : rebase_source : a17fe88eb92072935cb86f9ada4205863cfc8f85
It now only does something trivial, which also happens to be a no-op
because it's the default. It does have a commented entry for possible
gtk+2 builds, but we're soon going to remove that possibility anyways in
bug 1278282.
--HG--
extra : rebase_source : 0de751e523ee002bbe6638d223eb384364edd22b
Now that build environment docker images have gtk+3 installed in
/usr/local, adjust mozconfigs to point pkg-config there, and remove
all the glue that was required to build using the tooltool package.
Also remove the --x-libraries=/usr/lib on 32-bits builds, which only
confuses the linker.
--HG--
extra : rebase_source : 22b1273ae4b78807b355d33ed5895bdfe83a141d
Back when we started needing gtk+3 to build Firefox, we were using mock
to setup the build environment, and a tooltool package was the most
sensible way to handle this.
Fast forward to today, and we're close to moving the build environment
to Debian, which comes with gtk+3 packages. But in order to simplify
the various checks for the transition, it is desirable to stop using the
tooltool package. Which we can actually do in a reasonable way now that
we use docker images instead of mock, by building and installing gtk+3
in the build environment images.
So we modify the script that was producing the gtk+3 tooltool packages
such that it installs gtk+3 in the docker images, both 32 and 64 bits.
And invoke it when creating the desktop build environment docker images.
--HG--
extra : rebase_source : fe18bfb2ec8db183c44838d5a7a0051322b2a9c0
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
Bug 1325632 added some facility to add target compiler flags. This
change extends it to add allow adding host compiler flags as well.
--HG--
extra : rebase_source : 424b405a1d8f9a4778ff75c3308c9622f050e194
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 366dd966cafe4f07b8e59fc170d2db2dada32627
Both the cc crate and the rust compiler may want to use "cc", which,
on automation, points to the system GCC compiler instead of ours.
As a workaround, we add a cc symbolic link in the GCC toolchain artifact
so that, as long as the GCC toolchain artifact's bin directory is in
$PATH early enough, it's picked over /usr/bin/cc.
--HG--
extra : rebase_source : 53cacf8a750539706a484218e168c8c9e0ba49a6
The "contract" for toolchains is that extracting foo.tar.xz creates a
directory named foo/. That is however not true for mingw32.tar.xz, which
extracts into gcc/, possibly overwriting files from the gcc.tar.xz
archive (which is also used for mingw builds, for the host part).
This is also not true for nsis.tar.xz, but it reportedly has problems
when it's not in the same directory as mingw32.
But mingw32 doesn't actually need to be mixed with gcc, so it's better
to separate them as they are supposed to be.
--HG--
extra : rebase_source : 30d90af64459bbb31bc076e48f3c661fa9cd4a79
We need MOZ_UI_LOCALE even when building the JS shell so
config/config.mk variable assignments don't run into issues. But it
doesn't make any sense to configure a UI locale for the JS shell. So
make --enable-ui-locale a normal `option`, but give it a `default`,
which is the value shell-only builds will always see.
--HG--
extra : amend_source : 047759dd6ec446d9d6f8f5992ed9cf6628ce859e
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
lld is being too smart for its own good, and places non-relocatable data
right after the program headers, which prevents the program headers from
growing. But elfhack wasn't checking for that, so happily placed the
non-relocatable data at its non-relocated location, overwriting the last
item of the program headers.
--HG--
extra : rebase_source : 6f26d475f0a19d88ddf21399dbce8ceac62b492d
Bug 1385783 changed things such that the two elfhack sections are not
adjacent anymore. They can even be in different segments in some cases,
but the undo code doesn't know how to actually handle that case.
So for now, allow non adjacent sections, but still verify that they are
in the same segment.
--HG--
extra : rebase_source : da95ef7df19eeea8dfd07b24f22e7bee18939b69
Bug 1423803 was attempting to remove the fallible library but didn't do
so on Android because of this bug. We can now fully retire it.
--HG--
extra : rebase_source : de38872a08d24768eadfbe81652cfcd6aa7aa041
Bug 1256642 introduced magic at the emitter level to determine whether a
binary contains C++ sources and should be linked with the C compiler or
the C++ compiler.
Unfortunately, the Binary() moz.build template always adds C++ OS
libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux
(stdc++compat).
The latter only ends up forcing every Binary() to be linked with the C++
linker, which is unfortunate, but doesn't cause much problems. The
former, however, involving OS libraries, the magic from bug 1256642
doesn't kick in, so we end up trying to link C++ OS libraries with the C
linker. Which ends up failing, because the libraries in STLPORT_LIBS
require -lm, which, while it's added by the C++ compiler when linking,
is not when the linkage is driven by the C compiler.
Because the fallible library, linked to all GeckoBinary()s is a C++
library, we still ended up linking with the C++ compiler on Android, so
this wasn't actually causing any problem... until I tried to remove that
fallible library in bug 1423803.
Anyways, the core problem is that moz.build evaluation is happening too
early to know whether any C++ sources are being linked together, so
there is no way the Binary() template can do the right thing. So this
change moves the logic to the emitter.
This also changes the type of STLPORT_LIBS to a list.
--HG--
extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f
upload-generated-sources tasks simply use `mach python` to run an in-tree
script, so they can save time by using a sparse profile.
MozReview-Commit-ID: LbXlibOP34W
--HG--
extra : rebase_source : c6b580b15671edeb700d191f651c79c6d6423394
Bump the minimum required Rust version now that 1.22.1
has been in stable release for more than two weeks.
Version 1.22.0 works fine everywhere but macOS 10.13,
but 1.22.1 was released the same day, so it's no harder
to upgrade to.
Also update the base-toolchain builds to ensure we
continue to build with this version.
MozReview-Commit-ID: GlRWUNE07G0
--HG--
extra : rebase_source : f37585db5633e6e64b02bc94c2516b5ab18c3e15
With all of our builds in Taskcluster now, we should never be uploading
symbols from build tasks. Unfortunately Windows builds were still doing so.
This patch removes MOZ_AUTOMATION_UPLOAD_SYMBOLS from all the in-tree
mozconfigs and a few other places so that it should always default off
(per moz-automation.mk). The rest of the uploadsymbols bits will be
removed once Thunderbird fixes their automation.
This patch was mostly autogenerated by running:
rg --files-with-matches UPLOAD_SYMBOLS browser/config/mozconfigs/ mobile/android/config/mozconfigs/ | xargs sed -ri '/.*UPLOAD_SYMBOLS.*/d'
sed -ri '/.*UPLOAD_SYMBOLS.*/d' build/unix/mozconfig.linux build/mozconfig.win-common build/macosx/local-mozconfig.common build/mozconfig.automation
Then mobile/android/config/mozconfigs/common and
taskcluster/scripts/builder/build-linux.sh were hand-edited.
MozReview-Commit-ID: Cy8kSEodSg4
--HG--
extra : rebase_source : 01caf1651b4eb428313e1f371aa585f8f34c4151
The upload-symbols task simply runs an in-tree Python script with
`mach python` so using a sparse profile will make this a bit faster.
MozReview-Commit-ID: 5HzwMf1FZLU
--HG--
extra : rebase_source : 74046b7917ee2e2ea7be0ec24f777f5fe819ef58
