cargo 1.19, and later cargo 1.20/rustc 1.19 gained support for the make
jobserver. But that doesn't work unless make passes the jobserver file
descriptors down to subprocesses, which it only does when there is a +
prefixing commands.
--HG--
extra : rebase_source : a00ffb7edb358243ac7b9469941ec6fb5ad84885
This is similar to bug 1301751, where something in rust seems to trigger errors
running dsymutil to generate debug symbols in OSX. We can set debuginfo=1 for
these builds as a temporary workaround for now, while we work on a more
permanent solution in rust and/or dsymutil. debuginfo=1 still gives us enough
info for stack traces, although without line info. debuginfo=2 would be useful
for debugging, but is irrelevant to crash reports.
MozReview-Commit-ID: DdA00GzVfWg
--HG--
extra : amend_source : 47d3573042098194a07f9b473e4a02c86a1eba7c
MOZ_REPLACE_MALLOC_LINKAGE was added back when there were problems with
getting weak references working properly for replace-malloc.
Versions of OSX < 10.6 needed flat namespace, but aren't supported
anymore.
Versions of Xcode < 4.5 required flat namespace + a dummy library in
order to produce proper weak references. There is virtually nobody still
building with such an ancient toolchain.
Keeping those around doesn't /really/ hurt, except recent versions of
Xcode don't expose dyldinfo in /usr/bin, used for the configure test.
Consequently, MOZ_REPLACE_MALLOC_LINKAGE ended up being set to use the
dummy library setup, which, by using flat namespace, now causes harm in
bug 1356701, causing bug 1378332.
--HG--
extra : rebase_source : e3edc1f2cf905943c33fafeb631f2f88fc87167e
Cargo recently introduced the `cargo check` command for shortening the
edit-compile cycle when working on large programs. Since we don't
really support invoking `cargo` directly, let's wire up this command to
`mach`. Gecko developers can then `mach cargo check` to ensure their
changes typecheck.
All the machinery we set up for `cargo build` is equally useful for
other commands, such as `cargo check`. Let's refactor things so that
it's easy to reuse said machinery for `cargo check`.
We currently only honor LIB_IS_C_ONLY for cases where we set a
LIBRARY (and, implicitly, REAL_LIBRARY) and FORCE_SHARED_LIB. For many
libraries, such as the libraries from NSS, we never set LIBRARY, which
leads to not setting REAL_LIBRARY, which leads to not honoring
LIB_IS_C_ONLY. This practice has not been harmful thus far (except
perhaps linking in more things than necessary to our NSS shared
libraries), but on some platforms, linking with the C++ compiler will
drag in more things than we would like.
Consulting LIBRARY first should not be necessary; checking
FORCE_SHARED_LIB should be enough to tell us if we're building a shared
library for the purposes of honoring LIB_IS_C_ONLY.
We can avoid the symbol visibility problem by putting
sanitizer/asan_interface.h in the config/system-headers.
--HG--
extra : rebase_source : bc81a81ef8970c3544febf06631740208583c7fa
Stable Rust currently has logic similar to the following for finding the
linker on Windows:
if VCINSTALLDIR in os.env:
search for things in PATH
if found, return, otherwise fallthrough
look for MSVC installations of various kinds
For our current MozillaBuild setup where we clear out PATH prior to
invoking Cargo, this works: even though VCINSTALLDIR is set and we
(unsuccessfully) search through an empty PATH, we'll still fallback to
looking for MSVC installations.
Beta Rust has altered this search strategy:
if VCINSTALLDIR in os.env:
search for things in PATH
return the result of the search, regardless of success
look for MSVC installations of various kinds
Note that in the above logic, if VCINSTALLDIR is set, we are only going
to try looking in PATH for an appropriate linker. Since PATH is empty
in our current MozillaBuild setup, beta Rust will therefore fail to find
the correct linker. This failure causes numerous problems.
Since Firefox is already trying to "clean" the environment that Cargo is
invoked in, we should work a little bit harder by unsetting VCINSTALLDIR
entirely, and simply force Rust to search for known MSVC installations.
Making this change makes stable and beta Rust behave identically.
(We don't have to worry about this distinction in automation, because
the "cleaning" code is only activated when we detect a MozillaBuild
shell.)
Since we set WINVER=601 after dropping Windows XP support, it is unnecessary to define LOCALE_SNAME. So, we should remove it to remove compiler warning.
MozReview-Commit-ID: EawbHAznXNA
--HG--
extra : histedit_source : d3157300315052048756c22ac2c999523d28679d
Final target Rust programs are currently not picked up and
symlinked/copied to ${objdir}/dist/bin because the RUST_PROGRAMS output
variable is missing from the if-condition.
This change causes Rust binaries from RUST_PROGRAMS to be placed alongside
the other final target programs.
MozReview-Commit-ID: 5OIH1UMmCq2
--HG--
extra : rebase_source : cfcff21e9371b920c895ad27df344008962d7471
These paths can contain spaces, particularly if they point into
${HOME}/.mozbuild on Windows. If people are bold enough to use the
Windows packages from llvm.org, the LLVM packages are installed by
default into C:\Program Files\LLVM, so paths from there would contain
spaces as well.
Procedural macros for rust are compiled as dynamic libraries.
The compiler subsequently loads those libraries at runtime
when it compiles crates which make use of them.
We pass the generic LDFLAGS to our linker wrapper which ensures
cargo links static libraries with the correct flags. However
this also means that any final system dependency libraries
end up linked into the procedural macro dynamic libraries
whether they use them or not.
When building on macOS 10.7, this causes a SIGTRAP when dlopen
calls CFInitialize for system libraries like Cocoa off the main
thread. We believe this is a macOS bug, reported fixed in macOS 10.9.
https://openradar.appspot.com/7209349
Work around the issue by stripping those libraries and Frameworks
from the linker flags we pass to cargo. We could do a more careful
job of parsing and removing all -framework and -lfoo arguments
inside the linker script, but since this is a temporary issue
while we're using older build machines, I thought just stripping
them once in the build system was simpler.
MozReview-Commit-ID: CGXD8ARvojj
--HG--
extra : rebase_source : 33f28e8fbafb43dbdd257d9162a6e792fca79e51
We're getting an intermittent failure running `hg manifest` in CI. I
have no clue why.
What I do know is that we now have the mozversioncontrol Python package
for containing utility code for interacting with version control. It is
slightly more robust and I'm willing to support it more than I am
check_utils.py.
This commit adds a new API to our abstract repository class to obtain the
files in the working directory by querying version control.
Since I suspect cwd was coming into play in automation, I've also
added a utility function to mozversioncontrol to attempt to find
a version control checkout from the current working directory. It
simply traces ancestor paths looking for a .hg or .git directory.
Finally, I've ported all callers of the now-deleted API to the new
one. The old code had some "../.." paths in it, meaning it only
worked when cwd was just right. Since we resolve the absolute path
to the checkout and store it on the repo object, I've updated the
code so it should work no matter what cwd is as long as a repo can
be found. I'm not 100% confident I found all consumers assuming cwd.
But it's a start.
I'm not 100% confident this will fix the intermittent issues in CI. But
at least we should get a better error message and at least we'll be
running less hacky code.
MozReview-Commit-ID: AmCraHXcTEX
--HG--
extra : rebase_source : 815ae369776577ad374333920fd645d412a55148
gfx/skia/skia/src/core/SkCpu.cpp might use sys/auxv.h to detect CPU feature. So we should add it to system-headers
MozReview-Commit-ID: SijyUYvLgn
--HG--
extra : rebase_source : 0b509c2f5b4f3272578ae511e9c69cf6b0999c42
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Build system switch for optional inclusion of libaom
for support of the Alliance for Open Media AV1 video
codec.
MozReview-Commit-ID: 2C4o1ogRS9v
--HG--
extra : rebase_source : d4a68f1fc4654895f62a905666f0b75726e20e7f
The Java Addons mechanism never got traction and is not Web Extensions
compatible. Removing it simplifies the product and the build system.
MozReview-Commit-ID: ABUxkqqMISa
--HG--
extra : rebase_source : 346f88882774f072316714cf637a54d771d81a9a
Several years ago, joey starting writing a handful of unit tests for
primitives in our make files. IIRC a lot of the impetus behind this
work was to flush out bugs between GNU make and pymake.
AFAICT the only survivor of these tests today is check_mkdir.py. The
test is a one-off and has been a bit fragile over the years,
contributing technical debt along the way. And as part of removing the
last references to pymake in automation, it is once again showing
itself and failing in a way that has to do with the way the test
is written and not an issue with the code it is testing. Enough is
enough. This commit removes the test and eliminates the technical
debt. I don't think it will be missed.
MozReview-Commit-ID: 3OzurtFbcyD
--HG--
extra : rebase_source : 6d3cf6121c90e9c47948862b8c4117bb1d3e5afd
For linking static libraries, rustc will use whatever `cc` it finds (or
the equivalent on Windows). For our purposes, however, `cc` is not what
we use to link and we may have additional options we would like to pass
to the linker.
To do this, we need to tell Cargo about our alternate linker (currently
only used for target compilations, on the theory that the host compiler
rustc finds is probably good enough) and we also need to pass our linker
options into the process. We do this with environment variables, which
is not a great solution, but works surprisingly well.
This alternate linker is disabled for ASan builds due to peculiar
crashes when running Rust build scripts and for Windows, because we
don't do any interesting cross-compiling there.
This change paves the way for injecting target- or host-specific
environment variables for a particular `cargo build` invocation. Doing
this is not strictly necessary: all of our current `cargo build`
invocations use mostly target-specific environment
variables (e.g. PKG_CONFIG_ALLOW_CROSS). But separating things out
makes the code notationally cleaner and also avoids weirdness when
target==host.
rustc generates .lib files for its libraries when compiling for Windows
(even using MinGW on Linux). But MinGW expects .a files. So we add in
rust-specific prefix and suffixes so MinGW builds can find the libs that
rustc generates. (And the RUST_LIB- variables default to the same vales
as the LIB_ variables otherwise.)
MozReview-Commit-ID: ClsA0YuJaxh
--HG--
extra : rebase_source : 7b46460c94ceb34b7a5a302ce91d3f1dca600041
