Differences between revisions 21 and 28 (spanning 7 versions)
Revision 21 as of 2018-10-27 00:39:59
Size: 4765
Editor: PaulWise
Comment: uberjars
Revision 28 as of 2020-04-25 23:38:51
Size: 5240
Editor: PaulWise
Comment: see #919557 #922944
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
 * Code can be built non-fpic, which can be 5-20% faster due to register pressure, depending on arch. (Especially numerical code). NB: With gcc-5, -fPIC has less overhead on at least x86/i386: https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode  * --(Code can be built non-fpic, which can be 5-20% faster due to register pressure on register-starved archs like i386. (Especially numerical code).)-- NB: With gcc-5, -fPIC has less overhead: https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode
Line 33: Line 33:
Debian Policy unfortunately says that Built-Using may *only* be used for the purposes of DFSG/license compliance so tracking static linking must be done using custom headers.
Line 54: Line 55:
There is currently work ongoing by Michael Hudson-Doyle to support building shared go libraries. Support for dynamic linking (for amd64 only) will be in Go 1.5 which is due out in August 2015. Changes will be required to the Go packaging and dh-golang to support packaging Go packages as shared libraries. Michael Hudson-Doyle has tried building shared go libraries. Support for dynamic linking (for amd64 only) has been in Ubuntu for a while. But this plan is abandoned now. Even micro releases of the Go compiler break ABI, dynamic linking is just way too tedious, said by mwhudson.
Line 56: Line 57:
The golang tooling [[https://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160404/004169.html|generates Built-Using headers]] for direct dependencies, but not indirect ones. The golang tooling [[https://manpages.debian.org/unstable/dh-golang/dh_golang.1p.en.html|generates Built-Using headers]] for all(both direct  and indirect) dependencies.
Line 68: Line 69:
The default for Rust is static linking but dynamic linking is available with {{{rustc -C prefer-dynamic}}}. The default for Rust is static linking but dynamic linking is available with {{{rustc -C prefer-dynamic}}}. The ABI is [[https://lwn.net/Articles/797616/|not stable but this is being worked on]].
Line 73: Line 74:

Some browser extensions (webext-* packages) copy their dependencies at build time instead of symlinking, because some browsers ([[DebianBug:922944|Firefox]]) do not follow symlinks installed into /usr/share/webext/.
Line 92: Line 95:

Do browserify from package postinsts?

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.
  • It prevents memory sharing between different executables using the same code.
  • It renders some security measure less effective (ASLR for example).
  • To comply with the DFSG and GNU GPL, we need to keep old source around.
  • Possible to ship incomplete libs. Eg. foo() depends on bar() but bar() not present at link time.

Upsides

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. Debian Policy unfortunately says that Built-Using may *only* be used for the purposes of DFSG/license compliance so tracking static linking must be done using custom headers.

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.

OCaml

All OCaml libraries are statically linked into the final binary.

The release team have a transition that tracks OCaml rebuilds.

Go

The go tool from golang currently requires all libraries be available in source form and then builds everything into one binary. These source files in the -dev packages are the equivalent of the .a file.

When using gccgo-5 (go -gccgo), the Go runtime library is dynamically linked against an executable, however everything else is again linked "statically".

Michael Hudson-Doyle has tried building shared go libraries. Support for dynamic linking (for amd64 only) has been in Ubuntu for a while. But this plan is abandoned now. Even micro releases of the Go compiler break ABI, dynamic linking is just way too tedious, said by mwhudson.

The golang tooling generates Built-Using headers for all(both direct and indirect) dependencies.

Lisp

Lisp libraries are cl-* packages shipping the source code in /usr/share/common-lisp/, similar to Go libraries. The compiler (e.g. sbcl) builds a static binary from all used cl-* packages.

FreePascal

The ?FreePascal Compiler (fpc) packages in Debian don't seem to use dynamic linking. See also here.

Rust

The default for Rust is static linking but dynamic linking is available with rustc -C prefer-dynamic. The ABI is not stable but this is being worked on.

JavaScript

browserify and other tools merge together multiple JS files for shipping to browsers.

Some browser extensions (webext-* packages) copy their dependencies at build time instead of symlinking, because some browsers (Firefox) do not follow symlinks installed into /usr/share/webext/.

Java/Closure

Java has "uberjars" which bundle dependencies into the pre-built jar files.

Mitigation

The Debian archive keeps around old sources referenced by the Built-Using header, marking them with the Extra-Source-Only header.

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

For safety reasons, binaries should be linked dynamically to include hardening features e.g. ASLR. A user should be able to presume that binaries shipped by Debian are safe to use in front-facing (e.g. web services) scripts, etc.

More automatic detection of static linking? #698398

Make it easier to add Built-Using?

Change debian-policy & lintian to discourage static linking?

Do browserify from package postinsts?