Elektrine lite

← Feed

@thingsiplay@lemmy.ml

2026-10-26 15:36 UTC

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).

Replies (1)

  • @Ferk@lemmy.ml 2026-10-26 16:00

    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. I’m talking about the compiler. ABI compatibility is a non-goal in the compiler itself. You’d need to make a new version of rustc that is more careful when it comes to optimizations. What distribution includes precompiled libraries (not user programs) in Rust? If you install a C library like libcurl via apt install, you get a precompiled .so file. If you install a Rust library like librust-serde-dev via Debian’s package manager, you do not get a precompiled binary. If you inspect that package, it is literally just a zip file of raw .rs source code that gets dumped into /usr/share/cargo/registry/. Putting all libraries into the git repo or using OS package managers to essentially maintain a registry just like cargo’s can work… but it’s duplicated effort in keeping everything well managed, updated, and depending on what manager you use, it might not offer as much flexibility (like how if you need 2 different versions of the same library in Debian, you’ll need workarounds if the maintainers have not created separate versions for it). Also, sometimes some libraries might only need a particular dependency when a particular feature flag is enabled… a package manager most likely would have to download all dependencies of every library you want to use since it does not know what build options you are gonna use when you install the package.

    Open ##5257026