This updates the following third-party dependencies of mozjs_sys:
gcc v0.3.40 -> v0.3.42
libc v0.2.18 -> v0.2.20
libz-sys v1.0.10 -> v1.0.12
pkg-config v0.3.8 -> v0.3.9
Since libc is updated, we also need to update the gkrust lockfiles to use the
new version, because leaving it at 0.2.18 will result in improper vendoring of
the crates (see bug 1336528). None of the other mozjs_sys crates are shared by
gkrust.
MozReview-Commit-ID: 5FHELF8YKD0
I want to get Servo vendored into servo/. The previous plan was to
replace the dummy geckolib with the real deal when the vendoring is
done. Unfortunately, this will require a significant `cargo vendor`
change, which we want to punt on for a bit.
So, this commit moves our dummy geckolib outside of servo/ so we
don't need to `cargo update` or `cargo vendor` when the real servo/
is installed.
The change to toolkit/library/rust/shared/Cargo.toml can be reverted
in the stylo repo to allow it to use the real geckolib.
We also update the taskgraph code for detecting Servo. Previously,
it looked for a file in the possibly-vendored servo/ directory. Once
the vendoring happens, this check will always pass. But without the
real geckolib, the Servo builds will fail. So, we change the check
to look for the real geckolib. This is implemented a bit hackily.
But it will be short-lived until we run `cargo vendor`.
MozReview-Commit-ID: CxGTwy6bK9j
268fa5f3bc25 grafted an old patch to define --features=servo in
rules.mk. That patch was written before RUST_LIBRARY_FEATURES
existed. This commit fixes it up.
MozReview-Commit-ID: L5atm5CsP8d
Update the vendored third-party dependencies for the mozjs-sys crate.
This picks up recent bug-fixes and reduces noise in unrelated runs
of 'mach vendor'.
The libc crate is also used by the rust url parser.
gcc 0.3.35 -> 0.3.40
libc 0.2.16 -> 0.2.18
libz-sys 1.0.6 -> 1.0.10
MozReview-Commit-ID: 5ri4nOtQQ1n
This patch also drops the pretense that rust-url-capi will be used from
outside of c++, or that it will be used outside of mozilla-central,
removing the ifdef __cplusplus code, and including the C++ header
"nsString.h".
MozReview-Commit-ID: BULhHf3DObe
In our current Rust world, we have the following dependency structure:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust
|
+--> gkrust-gtest
This structure results in link errors with multiply-defined symbols
between gkrust-gtest and gkrust with newer Rust releases when linking
xul-gtest.so. So we have to do something different.
Our new structure is:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust --+-> gkrust-shared
| |
+--> gkrust-gtest --------------+
and we enforce that a given shared library can only have at most one
Rust library that it depends on. Said Rust library is assumed to
include all significant Rust dependencies of the dependent static
libraries as well. (In the above structure, gkrust is simply a wrapper
around gkrust-shared, so gkrust-gtest doesn't have to include gkrust as
a dependency.)
To validate the PSSH init data passed to EME, I'd like to reuse the same
PSSH parser that the ClearKey CDM shared library uses. So move the code
out of gmp-clearkey and into its own library, so we can link it statically
into code that needs to use it.
MozReview-Commit-ID: 7xSUSmCueJz
This patch removes the memory usage tracking in the script that wraps the
linking of the xul library. This patch also generalizes the wrapping of the
xul linking process to all platforms.
MozReview-Commit-ID: HyncF3aVwdx
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
When building gtest libxul with LTO, the fact that
StaticXULComponentStart is not passed first to the linker makes the
linker pull the NSModule symbols out of all the other objects first,
presumably because linking the gtest objects (which appear first) pulls
code from the other non StaticXULComponent* objects first.
So, to make things link properly with LTO, we trick the build system
to always put StaticXULComponentStart first.
