Post by @Ferk@lemmy.ml

2026-10-26 15:28 UTC

I think one of the reasons why this is not done is because Rust deliberately pushes away from relying on precompiled binaries. Unlike traditional C compilers, for the Rust compiler trying to keep ABI compatibility is a non-goal… the Rust compiler retains the freedom to aggressively optimize how data is laid out in memory and how functions are called. So the binaries generated by one version of the compiler might not work in the next version… making it much harder to work the way we work with C. This means managing dependencies between rust libraries is a lot more involved… since you are essentially recompiling the library along with your project, so you need a way to download, not just the library headers as you would with C, but its entire sourcecode.

Replies (1)

@thingsiplay@lemmy.ml 2026-10-26 15:36

I think one of the reasons why this is not done is because Rust deliberately pushes away from relying on precompiled binaries. Rust? You mean the developers of Rust? That’s not a decision to make by them. Also the Linux distributions include many precompiled binaries. So I don’t see what this point is. My suggestion is not to download and use the libraries from third party repositories. The idea is to have all libraries in the repository of the project itself (such as Git) or the standard library in the package manager, matching the rustc compiler that is also packaged there. In example if Debian would include such packages, then this would become quasi industry standard version everyone can target. Basically the same thing that happens with Python in example. So it stays ABI compatible. I am not suggesting for full cargo replacement, and suggest not to depend on the registry of those. And I actually believe we will get to that point at some point when gccrs is ready (GNU Compiler Collection including Rust).

Open ##5256880