The need for --disable-install-strip in the mac mozconfigs comes from a
discrepancy in how stripping is handled between platforms. On Windows,
there is no stripping. On non-Mac unix, `strip` removes local symbols as
well as debug info and debug symbols. On Mac, it actually removes too
much, and one has to pass flags to remove both local symbols (`-x`) and
debug symbols (`-S`). Debug info is already in a separate file
(`.dSYM`).
For profiling reasons, we do ship e.g. nightlies with local symbols but
not debug info or symbols (or at least that's the intent). On Windows,
again, nothing to do. On non-Mac unix, we pass `--strip-debug` to
`strip` so that it keeps local symbols. That's where the discrepancy
comes in for Mac: the build system doesn't handle this at all, so the
mozconfigs contain --disable-install-strip to avoid stripping.
The build system should be doing what it's expected to be doing from the
start, without mozconfigs opting into anything.
AFAIK, we only really need the local symbols, so we can `strip -S` on
Mac when profiling is enabled, rather than `strip -x -S`. This also
significantly reduces the size of the installer for nightlies.
And while we're here, move the logic out of old-configure and into
python configure.
Differential Revision: https://phabricator.services.mozilla.com/D76789
Now that upstream winchecksec builds and works natively on Linux, use
that. That should solve the random crashes under Wine. If random crashes
still happen, it will be easier to debug anyways.
We bump to the last version that doesn't use vcpkg because vcpkg makes
things more difficult.
Differential Revision: https://phabricator.services.mozilla.com/D73405
This includes scripts that involve `tup`, jobs that build `tup` in automation, `tup.configure`, and related infrastructure and documentation.
Differential Revision: https://phabricator.services.mozilla.com/D73921
Now that upstream winchecksec builds and works natively on Linux, use
that. That should solve the random crashes under Wine. If random crashes
still happen, it will be easier to debug anyways.
We bump to the last version that doesn't use vcpkg because vcpkg makes
things more difficult.
Differential Revision: https://phabricator.services.mozilla.com/D73405
The builds that should be doing LTO now all have PGO+LTO enabled through
taskcluster, and the others shouldn't be wasting time doing LTO.
Differential Revision: https://phabricator.services.mozilla.com/D69174
--HG--
extra : moz-landing-system : lando
mozconfig.common.override is supposed to be a way for try pushes to change any options that may have been previously set. To do this effectively, it needs to be the last thing in the mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D69045
--HG--
extra : moz-landing-system : lando
mozconfig.cache is already pulled in via mozconfigs/common earlier in these files.
Differential Revision: https://phabricator.services.mozilla.com/D69006
--HG--
extra : moz-landing-system : lando
We only enabled hardening with an explicit --enable-hardening because we
needed a patch. That patch was applied to upstream clang 8.0.1, so we
can now enable automatically whenever using the right version.
The explicit --enable-hardening was also not applied to win64-aarch64
debug builds, and this indirectly enables it there too, matching other
debug builds. This also avoids breaking debug builds when enabling
winchecksec on cross builds.
Differential Revision: https://phabricator.services.mozilla.com/D68161
--HG--
extra : moz-landing-system : lando
This creates a new toolchain artifact that repacks a combination of the
linux64-clang compiler along with parts of the win64-clang-cl compiler.
This has multiple advantages:
- It removes some convoluted parts of build task definitions (limiting
that to only occur on the win-cross toolchain itself).
- It simplifies the build setup by not requiring to prepare for where
clang-cl.exe is.
- It speeds up getting compiler artifacts because the win64-clang-cl
artifact is very large (due to there not being a llvm shared library)
and bzipped, which is slow to decompress. Here, we only take what we
need for the cross builds.
- It adds the runtime files that e.g. PGO will require, and that
linux clang-cl insists lives in the clang directory, not the
win64-clang-cl one, and that would require some convoluted setup to make
it work with the two separate toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D66543
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset 85ea1d36da66 (bug 1515451)
Backed out changeset 779bc1fa07ae (bug 1515451)
Backed out changeset 0c6771b60b76 (bug 1515451)
The tweaks are essentially the same as for win64 builds, with the only
differences being the path for the VC binary directory and the addition
of a WINEPATH for the additional path to load the DLLs necessary to run
asmarm64.exe.
Differential Revision: https://phabricator.services.mozilla.com/D65481
--HG--
extra : moz-landing-system : lando
The tweaks are essentially the same as for win64 builds, with the only
difference being the path for the VC binary directory.
Differential Revision: https://phabricator.services.mozilla.com/D65480
--HG--
extra : moz-landing-system : lando
While here, change ${TOOLTOOL_DIR}/vs2017_15.8.4 to ${VSPATH} which
expands to the same thing without depending on the version of MSVC.
Differential Revision: https://phabricator.services.mozilla.com/D65475
--HG--
extra : moz-landing-system : lando
Also, set the target explicitly, rather than get it implicitly from
MozillaBuild being 32-bits.
Differential Revision: https://phabricator.services.mozilla.com/D65471
--HG--
extra : moz-landing-system : lando
With this and all the previous changes, the necessary mozconfig for
local cross-builds only contains DIA_SDK_PATH, WINDOWSSDKDIR and
--target.
Differential Revision: https://phabricator.services.mozilla.com/D65295
--HG--
extra : moz-landing-system : lando