Hello.
Paul Wise <pabs@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
Attachment:
signature.asc
Description: PGP signature