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
Several developers have reported hangs on native Mac builds. I think we should disable the flag on Mac hosts. Even if we could fix the current hangs, without coverage in CI for this build configuration, we're asking for more trouble down the road.
Differential Revision: https://phabricator.services.mozilla.com/D67007
--HG--
extra : moz-landing-system : lando
It turns out clang-cl adds an explicit /DEFAULTLIB:/full/path/to/runtime
to all the .obj it creates, which makes the linker add it on its own.
Differential Revision: https://phabricator.services.mozilla.com/D66368
--HG--
extra : moz-landing-system : lando
LLVM's new pass manager has been in the works for several years and has better optimization (sometimes much better) than the legacy pass manager. I think it's in good enough shape for us to try at this point.
While we only really need the new pass manager for shippable builds, as a general principle I'd like to use it as much as possible, to help catch bugs for upstream. Therefore this patch enables the new pass manager by default for all clang builds, with the only exceptions being compilers older than version 9, and xcode clang where we can't trust the version number. There isn't a specific problem with older versions; I just don't want to sign up for the support cost of debugging people's local builds that may be fixed already.
I don't expect it to be necessary, but just in case, an opt-out is available via `ac_add_options --disable-new-pass-manager`.
Differential Revision: https://phabricator.services.mozilla.com/D66109
--HG--
extra : rebase_source : 91df800146700e4958b8e645ebbd3cf7b11a2f1e
extra : source : 2f5aba2e2c099a1df26e3444ccec2be0b4ff4613
LLVM's new pass manager has been in the works for several years and has better optimization (sometimes much better) than the legacy pass manager. I think it's in good enough shape for us to try at this point.
While we only really need the new pass manager for shippable builds, as a general principle I'd like to use it as much as possible, to help catch bugs for upstream. Therefore this patch enables the new pass manager by default for all clang builds, with the only exceptions being compilers older than version 9, and xcode clang where we can't trust the version number. There isn't a specific problem with older versions; I just don't want to sign up for the support cost of debugging people's local builds that may be fixed already.
I don't expect it to be necessary, but just in case, an opt-out is available via `ac_add_options --disable-new-pass-manager`.
Differential Revision: https://phabricator.services.mozilla.com/D66109
--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
This was cargo culted from the autoconf equivalent, and while it makes a
command that does "$(PROG) foo" work because it becomes ": foo", that
may or may not actually be a desirable outcome.
OTOH, we do have some places where there are some "ifdef PROG" that are
just plain wrong when PROG is always actually set.
One place I do know that does check if the value is not ":" is for
OBJCOPY, which is still set from autoconf.
All in all, looking at all the check_prog(allow_missing=True) we have in
python configure, it doesn't seem anything is checking for ":", and that
doesn't seem like the right status quo.
Differential Revision: https://phabricator.services.mozilla.com/D65276
--HG--
extra : moz-landing-system : lando
- Remove the separate option() for MT, because it dates back from when
we needed `MT` not being an absolute path, but that hasn't been true
since bug 1290040.
- Extend what was done in bug 1617794 to MT, although the long term move
is to not rely on MT at all.
- Patch leftovers from bug 1613799.
Differential Revision: https://phabricator.services.mozilla.com/D64712
--HG--
extra : moz-landing-system : lando
Depending on the target, the assembler for Windows builds is one of ml,
ml64, or armasm64. Only for the latter currently are we looking for the
assembler with the .exe extension. All of them should be looked for the
same way, and we pick including the extension.
Differential Revision: https://phabricator.services.mozilla.com/D64260
--HG--
extra : moz-landing-system : lando
We're feeding old-configure with compiler and assembler as found by
python configure via ac_cv_* variables (abusing the autoconf cache).
When doing so, and when the assembler was provided via an environment
variable, while python configure resolves the path, old-configure
doesn't get the resolved path, because we're currently passing it the
path that was passed via the environment.
Now pass the resolved path instead.
Differential Revision: https://phabricator.services.mozilla.com/D64258
--HG--
extra : moz-landing-system : lando
While this works on Windows, because os.pathsep is `;`, it actually
doesn't work on non-Windows, because clang-cl is still expecting `;`,
but os.pathsep is `:`.
Differential Revision: https://phabricator.services.mozilla.com/D62862
--HG--
extra : moz-landing-system : lando
James Willcox
Christian Holler
Mike Hommey
Ricky Stewart
David Major
Noemi Erli
Arthur Iakab
Andi-Bogdan Postelnicu
Andreea Pavel
Tyson Smith
Mihai Alexandru Michis
Stephen A Pohl
Tooru Fujisawa
Chris Manchester
Bogdan Tara
Brindusan Cristian
Marco Bonardo