| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add rustc_args(), env(), and rust_dependency_map() methods to the
RustPackage class. They simply delegate to PackageState and
PackageConfiguration.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Note that, as shown in the testcase, package() works in the subproject
as well. This means that in the future the Cargo code generator can be
changed to reduce the amount of generated code and instead rely on the
package object.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
rust.workspace() is the entry point for global feature resolution.
It loads a Cargo.toml file and ensures that all dependencies will be
built with the correct set of features.
Fixes: #13404
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
Sometimes, a Rust static library's native static libs refer to
libraries installed in the rustc target libdir. This is always the
case for most musl targets (with the intention of making it easier to
use them on non-musl systems), and other targets can also be
configured to do this using e.g. the llvm-libunwind option when
building the standard libraries for the target. When rustc is
responsible for linking it will always add the appropriate directory
to the linker search path, but if we're not using Rust for linking, we
have to tell the linker about that directory ourselves.
The added test demonstrates a scenario where this comes up: linking a
static Rust library, built for musl, into a C executable. -lunwind is
in the native static libs list from the compiler, but it's referring
to the libunwind.a in the self-contained directory.
|
|
Produce -Cembed-bitcode for Rust, and also disable bitcode
generation when LTO is not enabled.
|
|
These are two ways to implement the same thing, and at the DSL level the
`rust_abi` provides needed flexability, but at the lower level where a
target is a thing, the `rust_crate_type` is still proving to be more
useful. So, keep the `rust_abi` in the Interpreter and don't let it leak
into the build layer.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
In the long term, dependencies that do not have a [lib] table will not
create an invocation of override_dependency; do not expect there to be
a handwritten meson.build that does it.
In particular, this is the case for extra-dep-1-rs in the "rust/22 cargo
subproject" test case, so change that to use the extra_deps mechanism
instead to invoke the subproject.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Make sure that they are checked against the correct extension
on Darwin.
Fixes: #7964
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
It is required to have unique library names for rust_dependency_map to
work. In the case we have foo crate in multiple versions, we have to
make sure their .rlib file have a different name.
|
|
Allow multiple targets for the same crate name, which is useful when the
same crate is used for both the host and the build machine.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fixes: #15028
|
|
Fixes: #15028
|
|
|
|
Extracted from a patch by Xavier Claessens <xclaessens@netflix.com>,
adjusted to make it compile with cargo.
|
|
When a Rust target depends on an intermediate Rust library (.rlib) which
itself has a dependency on a native static library, Meson's generated
rustc command line failed to collect and propagate the search paths for
these indirect native dependencies, leading to a linker error:
error: linking with `cc` failed: exit status: 1
= note: rust-lld: error: unable to find library -l:libf.a
collect2: error: ld returned 1 exit status
The root cause is that the intermediate .rlib's metadata correctly
stores the requirement to link the native library (via the -l flag),
but it does not store the library's search path (the -L flag); the
responsibility for providing the search path is therefore deferred
to the final link command.
Ensures that search paths for all transitive dependencies are collected,
allowing the final linker invocation to find and correctly link the
required native libraries.
Reported-by: Martin Kletzander <nert.pinx@gmail.com>
Fixes: 018d22482 ("ninjabackend: unify conversion from path to -L/-l", 2025-10-08)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
When a structured source contains non rust files, the backend may select
such a file to treat as the main file. That doesn't work obviously, so
instead filter the main file such that it must be a rust file.
|
|
Do not link with link_whole/bundle, to show linking issue with Apple ld.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
If any dependency has "sources" in it, the file from the dependency might
end up in the rustc command line.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
If a depedency includes object files, they have to be added to the doctest.
However, NinjaBackend was not running flatten_object_list on the doctest.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The test has a custom .h target that has the same name as the input in the
test's source directory. Sometimes a compiler could build a target that
intends to use the file in the source tree, but finds an incomplete
output of the custom_target, causing the test to fail.
To fix this, move the generated headers in a subdirectory of the build
tree.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fix my misunderstanding of the code before commit aede231ef ("ninjabackend:
pass objects to generate_rust_target from non-Rust sources", 2025-07-29).
Object files were added by get_rust_compiler_deps_and_args() to both the
main target and the doctest command lines:
objs, od = self.flatten_object_list(target)
for o in objs:
args.append(f'-Clink-arg={o}')
deps.append(o)
therefore they now need to be passed as the final argument of
get_rust_compiler_deps_and_args() for both command lines as well.
Failure to do so causes problems building doctests when the main
target has objects as well.
Add a regression test as well.
Fixes: #14897
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The introspection interpreter sometimes produces targets with no source
files; BuildTarget will then pick a random compiler, according to the
order in clink_langs.
According to the comment in sort_clink, clink_langs are supposed
to list languages from *lowest* to highest priority. However,
process_compilers_late() process clink_langs in straight order and
returns the first language; which is the one with lowest priority.
This became visible with the addition of Rust to clink_langs,
because Rust has limitation on the names of library targets, but
the bug existed before.
Fixes: e49f2f7283e1d9f18e2f5f54647c07287cd70339
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
A cargo package can build multiple crate types for the same library.
Using the same name in meson.override_dependency() fails.
[pbonzini: adjust documentation]
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
rustdoc does not support --print, and therefore the rpath argument corresponding
to the rust installation is not passed to doctests.
Forward anything that requires --print to the RustCompiler, thus fixing
doctests with a shared library dependency.
Fixes: #14813
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
As an initial implementation, simply adding "-C prefer-dynamic" works
for binary crates (as well as dylib and proc-macro that already used it).
In the future this could be extended to other crate types. For more
information see the comment in the changed file, as well as
https://github.com/mesonbuild/meson/issues/8828 and
https://github.com/mesonbuild/meson/issues/14215.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Because rustc does not support extract_objects, QEMU creates a static library
with all the C objects. It then passes this static library as link_whole,
together with another static library containing general purpose utility
functions which is passed as link_with.
However, this is brittle because the two have a circular dependency and
they cannot be merged because of the link_whole/link_with difference.
While lld seems to have the --start-group/--end-group semantics
automatically, ld.bfd can fail if these options are needed. This can
cause difference between distros depending on how Rust is packaged
(e.g. Ubuntu 22.04 and Debian bookworm seem to use ld.bfd).
The simplest solution is for Meson to implement "objects:" properly
for Rust. Then QEMU can use the same internal dependency objects that it
already has in place for C programs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Doctests have a slightly different output compared to what "protocol: rust"
supports:
running 2 tests
test ../doctest1.rs - my_func (line 7) ... ignored
test ../doctest1.rs - (line 3) ... ok
test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.12s
Add a little more parsing in order to accept this; a simple minded split()
fails to unpack the tuple. I plan to contribute an extension of the rust
module to invoke doctests, for now this allows running rustdoc --test with
"protocol: 'rust'" and get information about the subtests:
▶ 4/8 ../doctest1.rs:my_func:7 SKIP
▶ 4/8 ../doctest1.rs:3 OK
4/8 rust_unit_tests:doctests / rust doctest OK 0.28s 1 subtests passed
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Any argument from the base target is copied to the test target, but some
keyword arguments for libraries are not available in executable.
Remove them.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Cargo sometimes adds new keys and Meson needs to gracefully handle
those. Currently, an unknown key will trigger an uncaught Python
exception, which is pretty much the worse case. With this change Meson
will instead issue a warning much like the one for unknown cpu
architectures.
See #13826 for the motivation for this change
|
|
|
|
The library name defaults to its package name, but it can be different.
For example:
- package name: cairo-sys-rs
- library name: cairo-sys
- dependency name: ffi
|
|
Introduce a global Cargo interpreter state that keeps track of enabled
features on each crate.
Before generating AST of a Cargo subproject, it downloads every
sub-subproject and resolves the set of features enabled on each of them
recursively. When it later generates AST for one its dependencies, its
set of features and dependencies is already determined.
|
|
|
|
aee941559 ("rust: recursively pull proc-macro dependencies as well")
had to be reverted (in a66cb97e8) because it broke Mesa cross
compilation. This happened because a C shared library was linked with
a Rust C-ABI static library, which caused it to inherit the proc macro
dependency the Rust static library was linked with.
The right way to handle this is for only Rust targets to inherit proc
macro dependencies from static libraries they link with. A Rust
executable, library, or whatever will need the proc macros its Rust
dependencies use, as illustrated in the test case that I've
reintroduced here.
I've verified that Mesa still cross compiles correctly with this
change. The same failure was also identified by the "rust/21
transitive dependencies" test case, but only when cross compiling, so
it wasn't caught by CI.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
|
