Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)
2017-05-18 19:52 GMT+02:00 Sean Whitton <spwhitton@spwhitton.name>:
> 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?).
Cheers,
Matthias
--
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
Reply to: