On Wed, 2013-01-02 at 09:15:59 +0100, Michael Stapelberg wrote: > Shawn <shawnland...@gmail.com> 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. This includes: - 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 be larger. * 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. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130102120546.ga31...@gaara.hadrons.org