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:
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
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.
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.
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!
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 :).
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
- 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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.