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

Re: Building and using shared libraries using gccgo



On Tue, Feb 05, 2013 at 04:36:44PM +0100, Joachim Breitner wrote:
> At least to me my work on Haskell in Debian feels more than pretending,
> and from personal experience with the creators of the language, I have
> strong doubts that they are Idiots.
> 
> In fact I don’t see how you can have modern features like
> cross-module-inlining without having to potentially recompile depending
> packages.
> 
> And it is clearly not (anymore) the case that ABIs are not handled in
> Haskell. In fact they are handled in a very precise way that allows us
> to guarantee on the package level that user’s installations won’t get
> broken. I think our priorities should be the user’s experience, and we
> should be willing to accept a little infrastructural complications on
> our side for that goal.

It's not a matter of "a little infrastructural complication", it's about
having the slightest chance of reasonable security support -- or even
regular bug fixes, when multiple layers of libraries are involved.

If there is a bug in library A, if you use static linking, you need to
rebuild every single library B that uses A, then rebuild every C that uses
B, then finally every single package in the archive that uses any of these
libraries.

Just imagine what would happen if libc6 would be statically linked, and a
security bug happens inside (like, in the stub resolver).  Rebuilding the
world on every update might be viable for a simple scientific task[1], but
not at all for a distribution.

Static linking also massively increases memory and disk use; this has
obvious performance effects if there's more than one executable running
on the system.


[1]. Simple as for the number of diverse packages/systems involved.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ

Attachment: signature.asc
Description: Digital signature


Reply to: