On 8/15/2024 7:42 PM, Manos Pitsidianakis wrote:
Outstanding issues
==================
Outstanding issues that are not blocking for merge are:
- Cross-compilation for aarch64 is not possible out-of-the-box because of this
bug:
<https://github.com/rust-lang/rust/issues/125619> in llvm which when
fixed, must be ported to upstream rust's llvm fork. Since the problem
is an extraneous symbol we could strip it with objcopy -N|--strip-symbol
- Adding more than one Rust device ends up with duplicate symbols from
rust std library because we are linking as whole archives because...
constructors are stripped by the linker otherwise :( It can be worked
around if a single Rust library is built with all the devices as
dependencies which is then linked to qemu. The fix is a small change
which I will add either in a next version or when a new Rust device is
added.
Hi Manos,
I also noticed that when I tried adding a second device. Some other projects met
similar issues [1], but no clean solution seems to be available yet. The options
are:
1) Combining all crates into one staticlib which is linked to the final
executable. That requires generating one .rs with extern crate decls of all
enabled crates. In the context of QEMU, different targets may enable different
set of crates (e.g., some crates have arch constraints), thus one .rs for each
target will be needed in general.
2) Linking rlibs (or emitted objects) directly with other C objects using the C
linker. That somehow works (with some tricks) but is not officially supported
and may break in the future.
I'm working on (1), but would like to have your thoughts and preference on those
options.
[1] https://github.com/rust-lang/rust/issues/73632
---
Best Regards
Junjie Mao
