@coffecat

Wow, this is just great! Rust has always been on my TOLEARN list but it just gots ovewritten by AROS work all the time. Thanks for working on this port!

I'll look into SDK issues you mentioned (3 and 4) and get back to you.

PS. You can upload your binaries to https://archives.arosworld.org/. It's a standard way of distributing software for AROS.

Nice work coffeecat, and welcome. This is a real contribution, no drama incoming.

Small correction so credit lands right: it is John Knipper (me), and the file manager is Ferail. Ferail is written in rust.

The ports are aarch64 hosted under Macaros, so I cannot test your x86_64 binaries or setup.sh, but I can answer the parts that are not platform specific.

Since you mentioned it: the Zed port lives at github.com/jonx/zed-aros, branch aros-platform. This was a lot of work, even with using AI. C:Zed is Zed's own main, not a shim, rendering the real workspace on AROS with project panel, tabs, syntax highlighting and status bar. The new crate is gpui_aros, a software rasterizer blitting into an Intuition window through WritePixelArray, with Intuition menus and ASL requesters around it. Ferail is at github.com/jonx/Ferail and rides the same backend. Note the licensing split before you copy that path: the GPUI platform crates are Apache-2.0, Zed's editor crates are GPL-3.0-or-later. There is an Apache-only alternative at github.com/jonx/gpui-component-aros.

Zed is also worth mentioning for your std work, because a 236-crate graph is a merciless conformance test. It found two pal bugs that no probe of ours ever would, and both will hit x86_64 identically: the is_absolute one below, and all-zero st_ino values reading as a symlink loop, which made the worktree scanner refuse to descend into any subdirectory. You need std:s::aros::fs::MetadataExt for that one.

Your questions 3 and 4: not your mistake. libcrt.a and libexec.a genuinely both define close, and we carry -Wl,--allow-multiple-definition permanently in the target JSON's pre-link-args. Binding the C library's wrapper explicitly is what we do too. It is not a linking error on your side.

On stripping: use llvm-strip --strip-debug, not a full strip. Same failure mode we hit, and a debug-info binary takes minutes to relocate at LoadSeg, so you do want the partial strip.

Question 5, std. We have it running, and this is where I think we should join forces, because almost none of it is architecture specific.

Every sys/<feature> module in std ships an unsupported stub, so std compiles for a new OS on day one. Add aros to library/std/build.rs so it is not restricted_std, then replace stubs one at a time. Our first booting std was 9 files and about 194 lines: alloc, stdio, io/error, random. That is enough for println!, Vec, HashMap and format!.
process without fork: Command maps onto dos SystemTagList. Three traps. The Shell ends with return error ? RETURN_FAIL : RETURN_OK, so read the real exit code from cli_ReturnCode in an NP_ExitCode hook. An unset stdin must be NIL: or a child that reads stdin blocks forever on the console. Stdio::piped() works through PIPE: endpoints plus SYS_Asynch. We still have no safe kill().
net through bsdsocket: works, IPv4, via a small C glue file calling the LVOs. try_clone needs Dup2Socket. Timeouts and non-blocking are the rough edges.
random: HashMap forces this before anything else. AROS now has entropy.resource and arc4random upstream, so take that rather than writing a weak fallback.
errno will bite you the moment threads exist. A single global cell is not enough; per-task errno landed in stdc/pthread. There are also two errno cells in play, and the pal has to read the library one when its own is empty.
One trap worth the warning: without a sys/path/aros.rs, std falls back to the unix is_absolute, which is has_root() && prefix().is_some(). AROS parses no prefixes, so no path is ever absolute, not even /foo, and every crate that branches on it silently joins onto the cwd.
Dev loop: symlink the toolchain's rust-src at your own Rust clone so -Zbuild-std builds your pal. Cargo does not fingerprint through that symlink, so editing the pal does not rebuild std. Force it or you will debug a stale libstd.
The collaboration. The pal calls posixc, dos, exec and bsdsocket. None of that is aarch64. The genuinely platform specific parts are the target JSON (arch, data-layout, code model, relocation model) and the link recipe. So one shared sys/*/aros.rs could serve x86_64 and aarch64 with two target files, and the OS-side gaps you find get fixed once for both.

Your generated libc crate is the piece we do not have. Our pal declares private extern "C" prototypes, and real libc-crate AROS support is exactly what a rust-lang/rust tier 3 submission would need. Your libc crate plus our pal is a plausible path to upstream, which neither of us gets alone.

Ours is at github.com/jonx/rust-aros (same repo name as yours, so worth disambiguating in any writeup). Status and the known gap list are in hosted/rust/STD-PORT.md in github.com/jonx/Macaros. Happy to discuss further.

ps: this is cleaned up with AI, as it's very late right now for me

Entry text is outdated; I managed with std and compiled and ran ripgrep and tokio. I've noticed that in the AROS contrib there's the latest version of SDL3 so I plan to test it out in next days.
Next, I'll look at aarch. For Python, I will have a look, but I will likely need to come back with more questions

I've tested a couple of things, and it seems my knowledge is far behind what AROS can do. I'm just testing std for Rust now, and it looks promising.

Which means that Python 3.15 being able to run a REPL and launch scripts - very likely; Python 3.15 with a usable standard library and networking - likely. Full Python with pip and dynamically loaded C extensions, like on Linux - idk.

aarch for sure; since I work on Mac mostly this platform is a better target. But Rust is already on aarch in Macaros, IIRC?

I don't like Rust, but it's already a GREAT achievement. Kudos!

Next I hope that it'll be Python 3.15.

We also ask for a port to aarch64 for raspberry Pi

I spent the last few days getting Rust to build and run on AROS x86_64, and I have put the result up in case it is useful to anyone else:

https://github.co.../rust-aros

What it is

A target definition for rustc, a small runtime crate (allocator, println!, panic handler, and bindings to dos.library, exec.library, and SDL2), a project template, and an SDL2 example.

You build on a PC or Mac with the AROS cross-toolchain and get an ordinary AROS executable. A helper also lets cargo run deploy to a QEMU-hosted AROS. The archive includes prebuilt binaries, so you can try the examples without setting up a toolchain.

What works

* core and alloc, including Vec, String, format!, and the collections
* no_std crates from crates.io without modification; I tested libm and hashbrown
* Floating-point and 128-bit arithmetic
* Calling the AROS API and the SDK's C library directly
* SDL2

The SDL2 example animates a 320×200 plasma at around 227 fps inside emulation, with no hardware acceleration, so the software path is comfortable for this sort of thing.

I also generated a libc crate from the SDK. Type layouts were read from the cross-compiler's debug information, while constants were expanded from the headers. I then checked it against a running system.

File I/O, stat, directory listing, clocks, threads, and mutexes all behave correctly.

What does not work

The Rust standard library (std) does not work. Crates that require it will not build, and that is currently the main limitation.

Files, threads, and clocks are reachable through the libc bindings, but you call them as C functions rather than through std::fs or std::thread. Sockets aren't reachable yet, since on AROS they aren't libc functions.

The toolchain is nightly-only because custom targets and -Z build-std are not stable features.

Panics abort because there is no unwinder.

Binaries are larger than their C equivalents, and you must not fully strip them. A full strip leaves a binary whose relocations the loader skips, causing it to die before main.

Where this might help

* Writing new AROS programs without doing your own memory management, while still calling Exec, DOS, and Intuition at the boundary
* Pulling in existing no_std crates instead of porting C libraries, including parsers, compression libraries, checksums, and data structures
* Later, if std lands, porting modern software that contains Rust components without being blocked by the toolchain

Credit

James Knipping's Zed and ferail ports showed that Rust on AROS was possible. Those ports target AArch64 and run under Macaros.

This package is an independent x86_64 build. It is not the first Rust implementation for AROS.

Where I would like feedback

I have only tested this on AROS One 1.3 under QEMU, on one machine, so the useful questions are:

1. Does setup.sh find your toolchain and SDK, or does it guess incorrectly?
2. Do the prebuilt binaries in bin/ run for you, whether on Icaros, native hardware, or a hosted build?
3. For people who know the SDK well: there is no POSIX open symbol. The plain open in the link libraries belongs to exec.library, while the C library exports its own as __open_CrtBase_wrapper, which I bind explicitly. Is that the intended approach, or am I missing something?
4. Related to that, libcrt.a and libexec.a both define close, so anything mixing C file I/O with Exec calls needs --allow-multiple-definition to link. Is that a known wart, or a sign that I am linking incorrectly?
5. If anyone has looked at bringing std to AROS, particularly processes without fork and sockets through bsdsocket.library, I would be glad to hear how you approached it.

The project is MIT-licensed. Patches and comments are welcome, and I intend to keep the repository current. I will upload to AROS World if that's fine.

It's my first contribution, so I take cold showers and negative comments personally, and I promise to cause drama (/just kidding).