Static linking considered harmful

[Jakub Jelinek]

On Wed, Nov 29, 2006 at 01:15:33AM +1030, n0dalus wrote:
> Going through the main points on
> http://people.redhat.com/drepper/no_static_linking.html I don't see a
> lot of justification for the complete removal of static linking
> support in Fedora. So far the only proposed alternative to static
> linking is this approach of sticking the .so files in with the program
> and using LD_LIBRARY_PATH in a script -- which is almost just as bad
> as static linking.

You misunderstood part of this thread.
The bundling of shared libraries with the app was a suggested alternative
for those requiring bit-wise identical results from numerical apps, it is
definitely not meant as a general way how ISVs should ship their programs.

Those requiring bit-wise identical result intentionally don't care about
security (they even depend on bug-to-bug compatibility), they probably
even can't live with randomization (but that can be turned off with
setarch), etc.

For programs which don't have such requirements (the vast majority),
an analysis of the libraries the (dynamically linked) program links against
(or dlopens) is needed.  There are libraries which keep ABI stable and
maintain backwards compatibility (either through symbol versioning or
by strictly only adding new symbols, never changing the semantics of
old entry points or removing symbols), there are libraries that do that
mostly, but from time to time bump SONAME, there are libraries which
change their ABI (and bump SONAME) often.

For the first category (e.g. glibc, libX11), the rule of thumb is
link dynamically, don't include the libraries with your program,
compile and link against the oldest version you still want to support.
Say by compiling/linking against glibc 2.2.0, you should cover
RHL7.0 and higher (and other Fall 2000 and later released distros).
I think we can re-add compat-glibc, perhaps containing several sets
of headers and dummy link-only libs, to FE, then you just use
some compat-gcc* together with this compat-glibc* and can build even
on contemporary distros programs that run on older as well as contemporary
distros.

For the second category (e.g. libstdc++ especially if you want to support
even really prehistoric distros), you sometimes want to optionally
bundle a shared library with your program, but e.g. at install time of
the program check whether the system doesn't provide that library
(same SONAME and either as old or newer than what you are bundling)
and in that case use the system library rather than your own -
the OS vendor will then take care of security fixes in it, bugfixes
too, etc.  Though I guess most of the distro vendors these days
have libstdc++ 3.2/3.3 and 3.4/4.0/4.1 libs around, similarly with other
libs (crypto, etc.).

Then there are shared libraries which have ABI of the day, in that
case either bundle your own shared library always or link .a library
statically (-Wl,-Bstatic -lbfd -Wl,-Bdynamic), example here is e.g.
libbfd.

	Jakub