Web lists-archives.com

Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)




On Fri, May 19, 2017 at 06:43:13PM +0200, Matthias Klumpp wrote:
> 2017-05-18 19:52 GMT+02:00 Sean Whitton <spwhitton@xxxxxxxxxxxxxx>:
> > Hello Matthias,
> >
> > On Thu, May 18, 2017 at 04:37:58PM +0200, Matthias Klumpp wrote:
> >> Looking at what other languages with the same problem have done, there
> >> are basically two ways to deal with the issue:
> >>
> >>  1) Rebuild every reverse-dependency of the languages' compiler every
> >> time the compiler is updated. This is done by Haskell and OCaml and
> >> resulted in permanent transition trackers for the libraries.
> >>
> >>  2) Ship source code instead of libraries in packages, and compile it
> >> directly into the target binaries. That way, the maintenance overhead
> >> of the languages' packages is greatly reduced, but code is statically
> >> linked (boo!) and a lot of code needs to be rebuilt for every
> >> dependency (meaning more work for the autobuilders). This is done by
> >> Go, and apparently also the plan to do for Rust.
> >
> > Note that Haskell is statically linked, too.  We rebuild every
> > reverse-dependency of every library that changes, not just the compiler.
> >
> > Are you saying that with D, it's only changes to the compiler that are
> > problematic?
> 
> No. D can also build shared libraries even. The problem is that you
> can only combine libraries and binaries built with the same D compiler
> and the same D compiler version.
> This results in problems:
> If I have an application A that depends on (shared or static) library
> B, and we update the D compiler that was used to build both components
> initially, and then do an upload of application A, we will get linker
> errors. Since A is now built with the newer compiler and B still has
> the ABI used with the old D compiler, a mismatch happens.
> 
> So, if a new D compiler is made available in the archive, we would
> need to ensure all D stuff gets rebuilt in order.
> If source code is shipped, the code is only compiled once, so we
> wouldn't run in that issue (but doing that is maybe no so nice?).

You already wrote in this thread that there is hope that long-term there 
might be a stable ABI.

With a dozen libraries it would be easiest to just declare one compiler 
the default D compiler for buster that has to be used when using any of 
the D libraries shipped in buster.

All libraries should automatically get a dependency <compiler><abi> 
when built, and through their shlibs generate <library><compiler><abi>
at all rdeps.

libphobos2-ldc71 seems to be <compiler><abi> for ldc?

Every ABI-changing version of the default compiler will then be a small 
library transition that should be executed via the normal transition 
process.

IMHO this would be a better solution than any kind of "ship source code 
instead of libraries" hacks.

> Cheers,
>     Matthias

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed