Hello. Paul Wise <p...@debian.org> writes:
> On Thu, 2024-01-25 at 00:24 +0000, Wookey wrote: > >> People keep telling us (@ARM) how marvellous Rust is, and we keep >> telling them that it's useless in the real world until it sorts out >> the stable ABI/dynamic linking problem. > > IIRC that has been worked on for some years now, and IIRC > the static linking wiki page has some references about this. > > https://wiki.debian.org/StaticLinking This reminded me that I'm not even sure that I fully understand what Rust's remaining technical obstacles to achieving dynamic linking (at least within Debian) are. I'm ignoring the potential cultural or political issues that have been alluded to by others. My understanding – and please do correct me! – has been that three components are missing: (1) A stable ABI. (2) A way of dealing with generic types/functions across dynamic linking boundaries. (3) A way of dealing with macros across dynamic linking boundaries. From Debian's perspective, is really (1) all that important given that a stable release only has to deal with a specific version of the compiler? Could we not live with every new version of *just* rustc in sid introducing a transition with a rebuild of every Rust package? As for (2): Since Debian has the privilege of having a complete overview of the "closed system" of all Rust packages that we need to consider, could we not conceivably make a pass across all Rust packages in the entire archive and record every concrete version of every generic type/function ever used? Then when a particular library package is built, we would force the monomorphization of all the relevant types/functions in that shared library's public interface. This would require tooling support from upstream to force generation of monomorphized versions of types/functions when building each shared library, but that in itself does not seem impossible. (As a curious effect, the introduction of a new package may then trigger the need to rebuild some of its own dependencies due to new monomorphic versions of functions being needed that had not been seen in the archive before.) Similarly, for (3), could we expand every macro in every library as needed by every depending package in the archive? Just trying to get a handle on how far we are from a solution of sorts, apologies for any stupid questions. Best, Gard
signature.asc
Description: PGP signature
