Are there other options if I want to ship a 'FROM scratch' image with just a single Rust executable, and everything compiled in?

That to me is the main driver for MUSL.

▲

masklinn 3 days ago | parent | next [-]

The best option would be the x86_64-unknown-linux-none target (https://doc.rust-lang.org/nightly/rustc/platform-support/x86...) however it currently a tier 3 with a single maintainer (so it is technically available but unsupported).

If this specific use case is of high interest to you and you have some available bandwidth, contributing to it, maybe becoming a maintainer, and eventually organising a tier 2 MCP would definitely be a good idea.

▲

VorpalWay 2 days ago | parent [-]

Note that this is no-std no-alloc target, with all the limitations that leads to.

You could add alloc with a custom global allocator, but I don't even know what high perf global allocator you could use that wouldn't need libc. Jemalloc and mimalloc are out. Some embedded allocators would work (but those are rarely high performance, instead being optimised for small code and data footprints).

That said, with enough effort (quite a lot!) it would be possible to add support for alloc and std without libc on Linux specifically (since it has a stable syscall ABI).

What might be more realistic though is looking at relibc (a rust implementation of libc, made for Redox OS but from what I read it also supports Linux). But I haven't tried it and I don't know the state (or goal) of it.

▲

masklinn 2 days ago | parent [-]

> it would be possible to add support for alloc and std without libc on Linux specifically (since it has a stable syscall ABI).

Well yes that’s a Linux specific target so that’s kinda the point.

Technically you could do libcless on a few other platforms which are not actively hostile to it (yet) like freebsd, but that would have no chance of getting to tier 2 if it was even accepted.

▲

VorpalWay 2 days ago | parent [-]

I just remembered that there is also https://github.com/sunfishcode/eyra (but I think it might be a dead project) which is close to that, it had slipped my mind.

All of these are going to mean you can't link any (non-freestanding) C code, load any dylibs, etc. So you will be fairly limited in what sort of applications you can write. Forget most GUI frameworks, even native ones. You won't be able to load GL or Vulkan drivers for example. You are basically stuck with command line or servers.

▲

masklinn 2 days ago | parent [-]

I would hazard the guess that that’s perfectly fine. Desirable even. People who run scratch or alpine images and link against musl aren’t usually looking to write desktop applications or video games.

	▲	VorpalWay a day ago \| parent [-]
		I wouldn't mind having a standalone binary that anyone can download and just run on their Linux desktop, regardless if it is Arch, Alpine or Debian stable. With glibc that is a pain, I need to build in a container with tthe oldest glibc I want to support, and that still doesn't cover Alpine. And I dont know if a static musl build would even work for that either (if I need to be able to load GUI libraries).

▲

kccqzy 2 days ago | parent | prev | next [-]

You can do FROM scratch, and use still glibc; it’s just that you need to copy more than one file. I don’t really understand if you are already dealing with images why you still need the image to contain a single file.

▲

nazgulsenpai 3 days ago | parent | prev [-]

Same usecase here, I use musl for compiling self contained Nim utilities I use on containers and servers without having to deal with glibc hell.