Closed sunfishcode closed 11 months ago
Disclaimer: I don't know what I am talking about :)
I might be misunderstanding, but potentially eyra could appeal to the same group of people who are trying to use musl instead of glibc in their programs. Or am I getting it completely wrong? Potentially having it all in Rust all the way to Linux syscalls would also allow to have better opportunities for binary size reductions due to better tree shaking and LTO.
I think you're right, but the other side of it is, musl is already quite good at that use case.
Eyra can do whole-program LTO, so the question is, how much does this help in practice? There are also places where Eyra may have larger code size than musl, due to the code adapting C APIs to Rust APIs. I haven't ever looked at how much that kind of thing can be optimized away in LTO though.
Going musl means having to install at least one additional package (on Debian), and I don't remember it working so smooth (though this could be due to needing additional C libs). The aim was to have a statically-linked executable.
The rust musl target now bundles a libc.a, so it can now produce statically-linked executables with no additional packages installed.
The rust musl target now bundles a libc.a
I just tried building with just cargo
and not cross
(which bundles the musl toolchain) and it definitely doesn't "just work":
running: "musl-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-m64" "-I" "include" "-I" "/[...]/target/x86_64-unknown-linux-musl/debug/build/ring-2ced09fa97fa0c1e/out" "-Wall" "-Wextra" "-fvisibility=hidden" "-std=c1x" "-pedantic" "-Wall" "-Wextra" "-Wbad-function-cast" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wnested-externs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wstrict-prototypes" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-g3" "-DNDEBUG" "-o" "/[...]/target/x86_64-unknown-linux-musl/debug/build/ring-2ced09fa97fa0c1e/out/crypto/curve25519/curve25519.o" "-c" "crypto/curve25519/curve25519.c"
--- stderr
error occurred: Failed to find tool. Is `musl-gcc` installed?
From the error message, it appears your codebase depends on ring
, which includes C source code, which does appear to require an additional package. On my local Debian-derived system:
$ musl-gcc
Command 'musl-gcc' not found, but can be installed with:
sudo apt install musl-tools
$ sudo apt install musl-tools
[...]
And then building packages depending on ring
works. So, not completely out-of-the-box, but only a minor roadbump.
The situation is different for cross-compiling; if I use a target of aarch64-unknown-linux-musl on this x86_64 host, I get "error occurred: Failed to find tool. Is aarch64-linux-musl-gcc
installed?", and there is no suggested package for aarch64-linux-musl-gcc
. It appears there may be some third-party things one could install, but it is more of a hurdle.
So if you have C source code, you need static linking, and you need cross compilation, but only to Linux targets (and only on x86-64/x86/aarch64/riscv64), and you're ok using Nightly Rust, then Eyra may be more convenient than alternatives, if it works.
Is that enough? I don't know. Making Eyra an upstream Rust target would involve a fair amount of work, both on the Eyra side and on the Rust side. Is it worth doing this work, and asking people to help do this work, and asking Rust maintainers to take time out of their schedules to do this work? My guess is, if you asked a Rust maintainer how to solve that problem, they'd be more likely to think in terms of "can we make it easier to install an aarch64-linux-musl-gcc?" than "what if an entirely new libc?".
My big picture here is, I don't want to do a lot of pushing on this thing. I don't want to have to try to convince people about it. I want it to make sense. I don't know if that will happen, and I entirely accept that it may not.
You can potentially start with Tier 3 target and then upgrade it to Tier 2 and eventually Tier 1. As I understand, the amount of work necessary for Tier 3 target will be less than Tier 1/2, at least from rustc maintainers POV.
@yerke Would you be interested in volunteering to do the Tier 3 proposal? :smile:
Sorry, I don't think I have time to do it right now due to my current work project. :(
Thinking about this issue more, I ended up writing a Why? section for Eyra's README.md, listing current pros and cons.
set_var
alone is great reason for people to try eyra!
Neither this issue thread, nor the blog post or the resulting discussions, produced any indication that anyone would actually use this in the real world, so I conclude that there are no real-world use cases. If anyone has any other information, they're welcome to file new issues, reach out, etc.
As additional context here, even just going for Tier 3 will require figuring out how this target should work. Eyra is not like most targets, with an opaque system libc that Rust can just use without knowing anything about it. Eyra has a lot of Rust crate dependencies (by design). Do we need to add a "rustc-dep-of-std" feature to all of them, or is there another way?
Leaving this here for posterity: @morr0ne recently added x86_64-unknown-linux-none tier 3 target in Rust compiler in https://github.com/rust-lang/rust/pull/125023. I am not sure about his exact plans, but I guess eyra could an option there for implementing an equivalent of libc.
The primary use case for Eyra is to have fun. It's fun to hack on, it's fun to hear people trying it out and reporting back whether it worked or not, it's fun when people submit patches.
Sometimes people ask whether Eyra will ever become something more. It's unclear at this point. One of the things that makes this complex is that we don't have many real-world use cases yet. What real-world problems might Eyra today or in the future solve better than alternatives?