Some mozconfigs don't include mozconfig.linux*, and don't get gtk-related
definitions, so move them in a separate mozconfig. To avoid having two
files, one for 32-bit builds and one for 64-bit builds, rely on the
includer to set PKG_CONFIG_LIBDIR appropriately.
At the same time, move all the --enable-default-toolkit=cairo-gtk2 in that
new file in the case the gtk3 package wasn't pulled from tooltool.
Write a mozconfig fragment which makes the rust toolchain
provided by tooltool available for linux builds.
Use linux64 mozconfigs to enable rust for official builds of
that target. These aren't used outside of automation builds,
so including rust there will verify code on check-in without
requiring developers to install rust.
LTO changes in GCC5 make it break the assumptions made in the test-ctors
source. The simplest and more correct thing to do is to just force the
test files never to be built with LTO. They are meant to have a particular
layout that LTO might break at any time anyways.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
'make check' is somewhat special in that we want to trigger testers
before it finishes. Since moving sendchange into mach is difficult and
'make check' may be going away in the future anyway, just pull it out
for now.
Also remove the MOZ_AUTOMATION_*_SENDCHANGE flags since we aren't using
them.
Incidentally, this makes the build fail because stdc++compat.o then appears
twice on the libxul linkage command line. This, in turn, is because
widget/xremoteclient creates both a program and an intermediate library for
libxul. The Program() template adds stdc++compat to the directory data,
which ends up being added to libxul as well. The same kind of issue arises
when linking the gtest-enabled libxul.
While eventually we'll be able to avoid those problems, it's not the case
yet, so work around the issue by making expand-libs skip .desc files that
appear multiple times.
- Linux ASAN nightly builds do not do update packaging
- Only set mar properties if the mar file was actually created
- Unset MOZ_SIGN_CMD for pretty-* steps
