Re: [RFC] Go (golang) packaging
On Wed, 2013-01-02 at 09:15:59 +0100, Michael Stapelberg wrote:
> Shawn <firstname.lastname@example.org> writes:
> > Henceforth when a go program depends on a go library, those go
> > libraries are ALWAYS compiled in statically. Static linking causes
> > many problems for distributions like Debian, and therefore this
> Can you please tell us which specific problems are caused by static
> linking for Debian? I’m not aware of any.
Well, that's surprising, I would have thought this has been discussed
at lenght in the past, in any case here are several reasons (I'm most
probably forgetting others):
* Changes in libraries might require recompiling all of their rdeps.
- Bug fixes (security or otherwise, as pointed out in the thread).
- Performance improvements.
- Private dependencies, as they leak to rdeps. When a library uses
another library privately this dependency gets linked in directly
in all other rdeps, when that library stop depending on that
private dependency, all rdeps need to be rebuilt.
* We might need to keep the sources for all library instances that
have been linked into any other package, to comply with license
conditions (see the Built-Using comment on this thread too).
* Larger dependency chains. Because private libraries need to be
pulled in even by indirect dependencies, the sources and static
libraries need to be available at compile time, this means the
libfoo-dev dependencies and Build-Depends chains are going to
* Produces huge binaries (and packages), which use more memory that
cannot be shared across processes (unlike shared libraries).
The first point alone, make such things a PITA to manage in a
distribution, and are a waste of buildd and people's time who need
to coordinate those things. The rest imply a waste of resources or
added complexity which could be avoided.
> I’m somewhat hesitant to say “Let’s just use gccgo in Debian” because
> static linking is one of the advantages of Go (IMO, but also a shared
> feeling by the community I think) and the gc compiler is fast, which is
> another advertised advantage.
While it's true that static linking can produce varying degrees of faster
binaries depending on the conditions (architecture, amount of libraries,
etc), I don't think it's worth the tradeoff for the general case and I'm
having a hard time seeing a new compiled system language that does not
support shared libraries as a serious contender.