Differences between revisions 1 and 2
Revision 1 as of 2015-05-19 01:24:50
Size: 1637
Editor: PaulWise
Comment: static linking page
Revision 2 as of 2015-05-19 02:35:55
Size: 1636
Editor: PaulWise
Comment: reword downsides
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
In general Debian Policy [[https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static|allows]] static linking but they have various [[#downsides|reasons]]. In general Debian Policy [[https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static|allows]] static linking but it has various [[#downsides|downsides]].

Intro

In general Debian Policy allows static linking but it has various downsides.

This page aims to document the downsides and mitigations we have in place for those downsides as well as improving the situation in Debian around static linking.

Downsides

It requires rebuilding the world when the libraries change.

It is harder to track than dynamic linking.

??

Affected

Various technology in Debian uses or is affected by static linking.

C libraries

C libraries support static linking and files are named *.a and can be unpacked with the ar tool from binutils.

Packages can declare they were built using code from other packages by using the Built-Using header and the Debian archive keeps around old sources, marking them with the Extra-Source-Only header.

Lintian detects binaries that have been statically linked.

Haskell

All Haskell libraries are statically linked into the final binary.

The release team have a transition that tracks Haskell rebuilds.

Go

??

Mitigation

Manual binNMUs can be done for packages that declare a Built-Using header.