mustang VS compiler-builtins

It would be great for Rust to have a Linux target that doesn't use libc, but from what I've read, not many people are interested in this.

Found this as well: https://github.com/sunfishcode/mustang

Some discussion here: https://github.com/bytecodealliance/rustix/issues/76

On Linux there has been some attempts to get exactly this solutions, most notibly https://github.com/sunfishcode/mustang but the topic did not seem to fetch a prominent position on the supported feature list.

For Linux, Mustang already exists because Linux has a stable syscall API

Why bother with a libc at all, when you can skip it entirely on Linux!

Mustang is a project which is able to run some non-trivial programs written in Rust, such as ripgrep, without using any libc, on Linux.

Mustang is one way to take care of the tiny amount of "C" that runs before main().

This is more a Rust question than a Zig question. In Rust, the choice of a specific libc (or to not use a libc) is part of the "target", for example many hardware platforms have gnu/musl/none targets. See also relibc or mustang for pure-rust alternatives. Each libc alternative require some work to integrate into Rust.

There's a separate project for that, called Mustang. It's built on top of rustix and provides all those things. It's not super mature yet, but it is able to run ripgrep by itself: https://github.com/sunfishcode/mustang

I don't know which symbols are missing, haven't done anything on the llvm level. But I had the same problems creating a no-std no-libc application, if you add https://github.com/rust-lang/compiler-builtins as a dependency you should get all the symbols you need, std uses the same but if you want to use it outside of std you'll need nightly since it uses a lot a nightly features. It might apply to your case as well.

Ah, I see - you might be hitting https://github.com/rust-lang/compiler-builtins/issues/347.

There's a PR to the compiler-builtins crate which the rust implementation is based on.

I'm glad to inform y'all that after a year, the infamous LLVM ERROR: Not supported instr bug¹ has been finally fixed and today's nightly can compile for AVR back again! 😎

Then, some of the non-trivial things that are needed are already implemented and maintained in other crates, like memcpy and friends in compiler-builtins, all the math routines in libm and malloc in dlmalloc.

3.Use scons to compile, if errors jumped on link up, find the solution on its official Github.