Closed corthon closed 4 years ago
Were you able to solve your issue?
Didn’t find an answer, but didn’t think it warranted an issue yet. Was going to try the Reddit community or something to see if there was a suggestion there. Then I got distracted and it fell off my radar. ;)
-- [ Insert obscure pop-culture reference here. ]
On Jun 7, 2020, at 3:41 AM, Philipp Oppermann notifications@github.com wrote:
Were you able to solve your issue?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.
Opening an issue for this is fine. To answer your question: You could create a cargo workspace and put the configuration in the workspace root crate. Note that this only works when your workspace root is a package too, so you might need to create a dummy lib.rs
for that. For reference, the code that implements the memcpy
configuration flag is in https://github.com/rust-osdev/cargo-xbuild/blob/master/src/config.rs.
As an alternative, I would recommend you to check out the -Zbuild-std
flag of cargo itself: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#build-std. This flag allows you to cross-compile the sysroot directly with cargo. It does not activate the memcpy
feature, so this might work better for you.
As another note, linking multiple Rust staticlibs might result in linker errors because of duplicate rust_begin_unwind
symbols. One possible solution for this is to use objcopy
to localize all symbols of the staticlibs except for some specific symbols that should be visible to other staticlibs. We use this approach for the new version of our bootloader
crate: https://github.com/rust-osdev/bootloader/blob/a91fa97df6ff89951b9395ab1a8582bd41c37671/build.rs#L126-L129
I hope this helps!
We have an entire class of binaries that are compiled as staticlibs to be linked against existing intrinsics defintions (in a no_std environment). Do we have to define this in every TOML or can we update our cargo flags on the command line?
Thanks!