Similar to the existing LIB_IS_C_ONLY variable, these variables indicate
that the program in question has only C sources and so can be linked by
the C compiler rather than the C++ compiler. We need to add a little
more information to BaseProgram so we can avoid emitting periods into
Makefile variables.
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
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.
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.)
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 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
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.
Instead of using the -i flag to clean out the entire set of environment
variables, we explicitly just clear out the variables that are affected by
32- vs 64-bit builds in vcvars.bat. This still allows cargo to use it's
internal autodetection to do host/target builds as it wants when cross-compiling,
but also allows other things that rely on include directories and so on to
work properly.
MozReview-Commit-ID: 99SECKv1zQa
--HG--
extra : rebase_source : 2c2a7d79201b66ac3262afcc5f060936ca2e8fa2
This change brings Cargo closer to what our C/C++ build already does,
and some forms of Cargo failure are only diagnosed when you pass
`--verbose`, so let's eliminate that extra step for people.
For people working on Rust code, compiling in debug mode (Cargo's "dev"
profile) is convenient: debug assertions are turned on, optimization is
turned off, and parallel compilation inside of rustc itself can be
used. These things make the build faster and the debugging experience
more pleasant.
To obtain that currently, one needs to --enable-debug at the Gecko
toplevel, which turns on debug assertions for the entire browser, which
makes things run unreasonably slowly. So it would be desirable to be
able to turn *off* debug mode for the entirety of the browser, but turn
on debug mode for the Rust code only.
Hence this added switch, --enable-rust-debug, which does what it
suggests and defaults to the value of --enable-debug. For our own
sanity and because we judge it a non-existent use case, we do not
support --enable-debug --disable-rust-debug.
This commit moves symbol dumping to the compile tier, to be run via "syms"
targets. Tracking files are used for the sake of incremental builds, because
dump_syms may genearate multiple outputs whose paths are not known ahead of
time.
Minimal changes to symbolstore.py are made here. More extensive
simplifications will be made in a future commit on the basis of symbolstore.py
handling one file at a time.
MozReview-Commit-ID: 3mOP8A6Y7iM
--HG--
extra : rebase_source : bfe97afcdfc05b9e79f01577701c83e8b00eb4e9
This creates "syms" targets that depend on the corresponding "target" for
directories containing shared libraries or programs. These targets are added
to the main compile graph in automation, and can be invoked through a special
"symbols" target. A future commit will use these targets to dump symbols for
shared libraries and programs during the compile tier.
MozReview-Commit-ID: KLuvmqsK4Zj
--HG--
extra : rebase_source : 8d76b999cb6fac8f11168ac6ebfb58774dfc2d3c
This prevents the variables set in vcvars.bat from causing build failures when
cargo tries to process build scripts in an environment where the default rust
toolchain doesn't match the MozillaBuild shell (in terms of 32-bit or 64-bit).
MozReview-Commit-ID: 5VRnQToYUYf
--HG--
extra : rebase_source : 4ac11f13e17ab04e70c7cb6f60ff46865027f506
VPATH applies to everything, but vpath applies to files matching the
pattern it's given.
--HG--
extra : rebase_source : 17339820e34f4d2f3d4ddde1a8a4325e92bfdb9e
The code doing that was already excluding OSX, so we obviously don't
need it on OSX. On FreeBSD, afaict, USDT (userspace dtrace) probes don't
require that extra ELF object. Solaris presumably does, but the 6 years
old bug 702179 says it's not been working for that long, and configure
doesn't support Solaris targets anyways.
Keeping this build system code working past the changes coming in bug
1262241 is not guaranteed and can't be tested, so I'd rather get rid of
effectively dead code rather than trying to maybe not break it while
moving it.
--HG--
extra : rebase_source : b41ab77804c17529e2580ced8e8b5fd302ff7831
sutagent is no longer built or used; devicemanagerSUT is completely
unused. After this change, devicemanagerADB is the only implementation of
devicemanager, and test harness options like --dm_trans are eliminated.
Although bug 1322703 is backed out, we can remove -FS options to build SIMPLE_PROGRAM.
MozReview-Commit-ID: 7uO3We5hc5n
--HG--
extra : rebase_source : 6f909c4f38ba5a5bdffed7f9ca5be0030b9c681b
Depending on a library or program in misc during a pgo build causes extraneous
rebuilding due to an added FORCE dependency, so we stop adding it except during
the compile tier.
MozReview-Commit-ID: 91dZFa6IRzt
--HG--
extra : rebase_source : 9994a5c05865c81d95ea075c753e270d3c223570
Nathan Froyd
Chris Manchester
Matt Brubeck
Kartikaya Gupta
Tom Prince
Mike Hommey
Mike Shal
Ted Mielczarek
Henri Sivonen
Marco Castelluccio
Ralph Giles
Xidorn Quan
Wes Kocher
Robert O'Callahan
Carsten "Tomcat" Book
Michael Layzell
Geoff Brown
Makoto Kato
Sebastian Hengst