[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some more rust/cargo insights

From: Hartmut Goebel
Subject: Re: Some more rust/cargo insights
Date: Mon, 7 Jun 2021 18:26:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2

Hi John.

Am 07.06.21 um 17:13 schrieb John Soo:
Rust has a very well documented rfc process and we can at least bring it up that way.  I brought up the possibility of collaboration between rust and functional package managers on the rust Zulip, even.  They seemed to like the idea.

I'd be more than happy if you could start a RFC process then. This issue bugs us and other distros since many months. (I have not contact to the rust community and will not sign up at another proprietary communication platform (Zulip)).

My feeling on this is that we should partner with the Rust community to make shared library support from cargo a priority.

Our issue is a different one: Its about being able to reuse already compiled binaries - keeping current behavior of rust binaries being statically linked.

While this looks like being the same as dynamic library support, it is not: While for dynamic libraries you meet to ensure the very correct version of a "crate" is loaded, for static linking with pre-build binaries you only need to ensure this at build-time. (For guix, of course, both would not be a problem, but I doubt we can make rust people understand this. And other distros will still have the problem.)

rustc already has a notion for "static libraries", just cargo fu** it up. (Sorry for hard wording, but I'm actually quite angry about cargos' narrow-minded behavior).

So our task is much, much easier and doesn't require changed to rustc, only to cargo.

 Specifying an output directory is currently a nightly feature, that could be helpful.

Not exactly sure what you mean. But what breaks build with cargo are the *input* directories - and other magic which gets included into the "meta-data" for no reason.

In general Rust tooling does not compose with existing tools.  I believe they will be amenable to the thought that it should. If Rust wants to be used in the linux kernel, for instance, it should be easy to use with Make.

From your lips to God's ears. From what I've seen an read, I'm not convident they will change anything. I'd like to be proofed wrong, though :-)

Another path we should checkout is to see what Debian does. My understanding is that they figured something out.  Worth a shot, but I’d rather the problem be fixed upstream. It will just take collaboration.

I did not check their tollchain lately, but package-earch still does not show many packages <>. Last time I check, they basically do what guix does: compile everything from source - again and again.

Hartmut Goebel

| Hartmut Goebel          |               |
| | compilers which you thought are impossible |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]