Cross-compiling libcore for embedded development

Hi there,

I know there is rustup, but I can't use it as it's not supported on my system (DragonFly). Even if I could use rustup, the provided targets do not match the version of the rustc compiler I have on my system.

Are there any instructions on how to cross-compile libcore myself, for a none target? I used to be able to do just that years ago by using a nightly compiler and xargo (I haven't tried that yet, as I thought it's no longer the way to go and also because I don't easily have access to a nightly compiler).

What else I tried was:

# from rustc source
python x.py build --target thumbv6m-none-eabi --config config-arm.toml src/libcore

where config-arm.toml contains:

[target.thumbv6m-none-eabi]
cc="arm-none-eabi-gcc"
cxx="arm-none-eabi-c++"
linker="arm-none-eabi-gcc"

But that fails with a

thread 'main' panicked at 'All the *-none-* and nvptx* targets are no-std targets', src/bootstrap/sanity.rs:203:17

Yeah, I know that they are no-std targets, that's the reason that I want them :wink:

I am a bit lost here and I can't find any up-to-date documentation about that topic, nor can I spot the location in the CI script that produces the arm-none targets. Help greatly appreciated.

Regards,

Michael

I'm guessing rustbuild is complaining because it's trying to cross-compile rustc itself for those targets, not just libcore.

Do you know if there are any big issues preventing rustup from supporting DragonFly BSD? I feel like the best long term solution would be to get rustup working because it'll unlock a lot of nice stuff.

If rustup isn't an option then you can still use xargo. It should still work, even if the project is in maintenance mode.

Also, do some of the links from this article help in any way?

Thanks for your quick response!

To get rustup working means to get CI for DragonFly. Last time I tried, the Rust project did not have the resources to run a separate builder for DragonFly. That was some years ago, IIRC. Definitively, that would be the way to go!

Thanks, I will try xargo again. I just need to compile a nightly first :).

Btw, the article you are mentioning is mine. I ported Rust to DragonFly :).

3 Likes

This may not be the place to ask, but what needs to be done in order to have rustup successfully install on dragonflyBSD? Is this a rustup issue? a dragonflyBSD issue?

I think it's largely a rust issue. Right now, according to https://forge.rust-lang.org/release/platform-support.html, it's a "tier 3" platform, meaning rust supports it, but does not guarantee that it will build and does not automatically build artifacts. In order to be available in rustup, it would need to be upgraded to Tier 2 support.

I couldn't find the exact requirements for upgrading to tier 2 support, but I did some digging and I found notes from a relatively recent compiler meeting. These aren't official, but they come from someone on the team which makes these decisions, and it seems the unofficial process would have most of these requirements:

Right now, here's what I have for tier 2. I'm going to additionally add the requirement for infra signoff on CI.

At this tier, the Rust project guarantees that a target builds, and will reject
patches that fail to build on a target. Thus, we place requirements that ensure
the target will not block forward progress of the Rust project.

  • Any new tier 2 target requires compiler team approval.
  • Any new tier 2 target must have a designated team of developers on call to
    consult on target-specific build-breaking issues, or if necessary to develop
    target-specific language or library implementation details. (This team should
    in almost all cases have at least 2 developers.)
  • The target must not place undue burden on Rust developers not specifically
    concerned with that target. Rust developers may be expected to not
    gratuitously break a tier 2 target, but are not expected to become experts in
    every tier 2 target. and are not expected to provide target-specific
    implementations for every tier 2 target.
  • The target development team should not only fix target-specific issues, but
    should use any such issue as an opportunity to educate the Rust community
    about portability to their target.
  • The target must build reliably in CI.
  • Building the target must not take substantially longer than other targets.
  • Tier 2 targets must cross-compile from existing targets, and must not require
    builds on specific target hardware.
  • Where possible, tier 2 targets should to provide documentation for the Rust
    community for how to build and run tests for the platform, ideally using
    emulation.
  • The target development team should regularly run the testsuite for the
    target, and should fix any test failures in a reasonably timely fashion.
  • All tier 3 requirements apply.

The fully conversation is available at the Zulip archive: https://zulip-archive.rust-lang.org/131828tcompiler/52053designmeeting20190920.html#176198844 and has some more context. Here's the conversation link too, if you have a rust-lang Zulip account.

Thank you

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.