Whenever any two Rust static libraries are included
as static libraries anywhere in a CC dependency tree, we sometimes
get duplicate symbol errors. To avoid this, we no longer
directly link multiple rust static libs to CC modules.
Instead, we build rust_ffi_rlib modules and produce the actual
static library that gets linked against the CC module based on
that CC module's full list of Rust rlib dependencies.
This introduces a new static_rlibs property for cc modules to
define the rust_ffi_rlib dependencies, which are then used to
generate the module above.
This CL is intended to deprecate rust_ffi_static. It leaves
rust_ffi_static and rust_ffi static variants in place until
the remaining rust_ffi_static declarations and uses can be
removed. In the meantime, rust_ffi_static produces
rust_ffi_rlib variants as well to make the transition easier.
Bug: 254469782
Test: m # with no changes
Test: m libapexsupport # with static_rlibs
Test: m libunwindstack # with static_rlibs
Test: m netsimd # with static_rlibs, no duplicate symbols
Test: m blueprint_tests # New Soong tests
Change-Id: I47e27ac967ef0cad46d398ebf59d8275929ae28a
The cc property include_dirs is neverallowed in certain paths since it
has been deprecated. The property in rust_ffi modules with the same name functionally works the same way as the CC property export_include_dirs.
To reduce confusion, and avoid triggering the neverallow rule, deprecate
include_dirs and create an export_include_dirs property which does the
same thing. This brings rust module properties into better alignment
with cc module property as well, reducing confusion.
Bug: 330736943
Test: New Soong test
Change-Id: Ib2020a22e6747ac690c46dbff84e38744f93ed15
This reverts commit e7c71c344d.
The intermediates created by the separated rust compile steps are very
large, on the order of 60GB. This is more than CI can support for now,
revert the split into compile and link phases. This comes at the expense
of incremental build time, especially when modifying C/C++ sources that
are dependencies of rust modules.
Bug: 293349612
Test: builds
Change-Id: I81169e7d0727330c8de5e7688dcdc87fe7b8d3b5
This commit adds support for compiling rust rules inside the sbox
sandbox. To compile a rust module with sandboxing enabled, the entry
point to the crate must be specified via the `crate_root` property, and
all input sources and compile-time data must be specified via the `srcs`
and `compile_data` properties.
Bug: 286077158
Change-Id: I8c9dc5cf7578037a583b4be2e2f73cf20ffd4408
This removes the dylib-std suffix from rlib variants which link against
libstd dynamically. This is by far the common case.
This fixes an issue where 'm <rust_library_rlib>' would fail since Make
would expect the suffix to be included (e.g. 'm libfoo.dylib-std').
Bug: 173312517
Bug: 268086496
Test: m <rust_library_rlib> # without a suffix
Change-Id: I1e5778c57468302a8d672d5eb540047d8bb79314
Teach rustc to generate object files instead of a linked executable
for binary and shared library crates. This lets us skip the lengthy
Rust compilation phase when only the C++ dependencies of these crates
have changed.
This works using a Python script that replaces the linker invoked by
rustc and converts the linker command line into a rspfile that can be
used during the link phase. The script makes certain assumptions about
how rustc invokes the linker, but since we control the version of Rust
we use, we can update the script if those assumptions ever break. I've
asked the Rust developers about adding an official way to do this so
hopefully we won't need to rely on this hack in the future.
The rustc rule for Kythe has been altered to pass linker=true, somewhat
consistent with the main rustc rule, which now doesn't invoke the actual
linker either. `m xref_rust` still succeeds, but hopefully we can find
someone who knows more about the rest of the Kythe pipeline who can let
us know whether it should still work. Otherwise, let's use this CL as
an opportunity to find out whether the rest of the pipeline is happy
with linker=true, since otherwise we will find it hard to maintain the
Kythe rule in the future.
Change-Id: Ifb9c8689c1bd78c0afcf6fdfd111140d20377536
What we call “static” in Soong is called “staticlib” in Rust, see
https://doc.rust-lang.org/reference/linkage.html for details.
Bug: 254469782
Test: atest
Change-Id: I65bba511d3ce8e7e53c6a1de3e77e30568934ce7
The two “rust_ffi_host” modules looked different in my editor because
one was indented with TABs and the other with spaces. They now
consistently use spaces (like the other examples in this file).
Test: atest
Change-Id: I7d0cdba5978da92a1a299bb290472403d4f13462
Allow adding rlib-only libraries to rustlibs by having it fallback to
selecting the rlib variant if a dylib variant is requested but not
available.
Bug: 224771894
Test: m nothing
Test: New Soong test
Change-Id: I47b19ec9dbf3da90a2b090aeda04556a0400c7d1
Rust installed files reside in "$MODULE_OUT/stripped/" when they are
stripped, otherwise they reside in "$MODULE_OUT". However, other parts
of Soong assume that installed files are always in $MODULE_OUT
(cc_modules place *unstripped* files in $MODULE_OUT/unstripped).
This notably causes problems when adding Rust modules as test data in
AndroidMkDataPaths. When Rust modules are parsed by AndroidMkDataPaths,
if they are stripped then they incorrectly get installed as test data
with the path:
<install_root>/<relative_install_path>/stripped/file.
This CL refactors how we handle Rust stripped output such that the
installed file always resides in $MODULE_OUT.
Bug: 171710847
Test: Installed files now always reside in $MODULE_OUT
Change-Id: I53a6ff57a0a5a55cd95ea78ae592ce22abfa20c9
Write toc files that list the exported symbols so dependents are
only rebuilt if the exported symbols change.
This exports the CC function TransformSharedObjectToToc, and also
removes an unused arg from its signature.
Bug: 178185435
Test: New Soong test passes.
Test: m <toc file path>
Change-Id: I7ab69bf7e7f32f25eb4c7ca9d18d877dac1511db
Adds an android_dylib cfg when building a Rust crate as a dylib. This
cfg lets us make the hack to add a dependency on std for the
panic_handler and eh_personality conditional on actually building a
dylib.
Test: m nothing
Bug: 193087363
Change-Id: Idad5b98245264f916afa327812a435b368f99321
Moves the prefer_rlib property out from being exclusively a binary
property to one thats part of the base compiler properties. This
provides a little more control over the libstd linkage in our libraries.
Specifically, this enables a usecase where rust_ffi_shared needs to link
against libstd statically rather than dynamically.
Bug: 175121262
Test: New Soong tests pass.
Change-Id: If68014c684a75ba70e9d7dacbb01c7d360dc25a1
This reverts commit 323dc60712.
Reason for revert: Possible cause of test instability
Bug: 170513220
Test: soong tests
Change-Id: Iee168e9fbb4210569e6cffcc23e60d111403abb8
Putting t.Parallel() in each test makes them run in parallel.
Additional t.Parallel() could be added to each subtest, although
that requires making a local copy of the loop variable for
table driven tests.
Test: m checkbuild
Change-Id: I5d9869ead441093f4d7c5757f2447385333a95a4
The current state of linkage is that device targets always link
libstd dynamically except for rust_ffi_static which requires a static
libstd linkage. However this prevents producing rust_ffi_static
modules which depend on other Rust libraries as those dependencies
will link libstd dynamically and cause a collision. We also want our
rust_test modules to statically link in libstd as well.
This adds a linkage mutator for rlibs that creates a variant for each
libstd linkage. Dependent modules can then select the variant that
matches their linkage of libstd.
Also fixes an issue where installation paths were being generated for
rlibs and static libs even though they weren't being installed. This broke
when adding the linkage mutator as Make would complain about multiple
targets producing the same output.
Bug: 168729404
Test: rust_ffi_static module with other rustlib dependency can be built.
Change-Id: I955b484bf5809e8fc5517750c7f8df82d3ca8895
Reuses the cc.Stripper logic. Abstracts Stripper to avoid the spreading
of references to the cc package.
rustc requires unstripped libraries (precisely, with the `.rustc`
section) when building dependent targets. Contrary to cc, the output of
a compiler module will remain unstripped and only an extra build rule
will be added. This rule will be referenced at install time (in
baseCompiler.install or androidmk).
This change drastically reduces the size of the installed libraries:
(unstripped, from out/target/product/crosshatch/system)
$ find . -name \*.dylib.so -print0 | du -c --files0-from=-
149996 total
(stripped, with this change)
$ find . -name \*.dylib.so -print0 | du -c --files0-from=-
42380 total
Bug: 153430439
Test: cd external/rust; mma
Change-Id: I94fd8bbcec97e0610aa325d3db4460be84d01734
Device binaries currently are linked statically by default. Instead we
should be linking these dynamic by default. To avoid conflicts when
manually specifying rlib dependencies on modules, we always link libstd
dynamically for all device modules except static libraries.
This removes the "prefer_dynamic" property entirely to avoid confusion.
Bug: 165161105
Test: m profcollectd is built dynamically.
Test: cd external/rust/; mma
Test: cd external/crosvm/; mma
Change-Id: I25ac897040acbcc2d97c791a33e8e01610632272
Adds the rustlibs dependency type which will automatically select
between rlib and dylib based on the type of the library.
Bug: 143217452
Test: cd external/rust; mma
Change-Id: I97faadae98bf957090a32939cfb2d3a10f74a057
rust_library now produces only rlib and dylib variants.
rust_library_foreign now produces static and shared variants.
This change was made because both are common cases, but all four
together essentially never happens. This allows us to have fewer repeat
module definitions.
Bug: 143217452
Test: cd external/rust; mma
Change-Id: Iaf69e8da38f7c12710331c51464699cf7cbbb656
Bug: 144861059
Test: cd external/rust/crates; mma
Test: Manual verification through ldd that libstd is a dependency
Change-Id: I603cf519215317aa8c400cd0f6ebb1b58f5bcf15
Without specifying -soname, cc binaries are unable to locate Rust
provided shared libraries. This adds the -soname linker flag for shared
libraries.
Bug: 158490355
Test: readelf -d <cc_binary> shows the expected SONAME
Change-Id: I66852a7ce24d5ea5e426f11bc1834fb56a150628
rustc expects libraries and proc_macro filenames to conform to
a particular format, alphanumeric with underscores and lib${crate_name}.*.
Enforce this with a check when getStem() is called.
This makes the crate_name property required for proc_macros and
libraries. This also removes the notion of a default crate name derived
from the module name. It's not needed for binaries, so this won't impact
them.
Bug: 143579265
Test: m -j crosvm.experimental
Change-Id: I2770cf7d02dd4291c3d240d58d242b940098dcee
Adds the ability for rust modules to be compiled as C libraries, and
allows cc modules to depend on these rust-generated modules. This also
means that soong-rust should not have any dependencies on soong-cc aside
from what's required for testing.
There's a couple small fixes included as well:
- A bug in libNameFromFilePath that caused issues when library's had
"lib" in their name.
- VariantName is removed from rust library MutatedProperties since this
was unused.
Bug: 140726209
Test: Soong tests pass.
Test: Example cc_binary can include a rust shared library as a dep.
Test: m crosvm.experimental
Change-Id: Ia7deed1345d2423001089014cc65ce7934123da4
Adds support to Soong for building rust modules. This currently only
supports x86_64 device and x86 linux host targets. The functionality
is sufficient to build crosvm.
Bug: 136189233
Test: Test module builds.
Test: crosvm builds.
Change-Id: I6ea04615834a6d673578ab10ea1a2eb04259fe09
