This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Static Linking
- From: Jonathan Nieder <jrnieder at gmail dot com>
- To: libc-help at sourceware dot org
- Cc: Julius Schmidt <aiju at phicode dot de>, "Laros, James" <jhlaros at sandia dot gov>
- Date: Tue, 22 Feb 2011 13:18:11 -0600
- Subject: Re: Static Linking
- References: <alpine.LNX.2.00.1102221912110.2157@sampi><alpine.LNX.2.00.1102221915350.2157@sampi>
Hi,
Julius Schmidt wrote:
> Some functions in glibc like gethostbyaddr don't like to be
> statically linked (well, you can, but they require the dynamic
> libraries, defeating the purpose of static linking)
If I had to guess, this change was introduced in cvs/glibc-2_3_3~505
(nis/nss_compat/compat-*.c: Don't use our own NIS/NIS+ functions,
dlopen corresponding NSS module instead, 2003-06-26). Searching
libc-alpha yields [1] which suggests it was used to make the
nameservice switch _extensible_: that is, /etc/nsswitch.conf can
request use of an NSS module that didn't even exist when glibc was
built.
And that is just good software engineering practice.
[1] http://sourceware.org/ml/libc-alpha/2003-04/msg00305.html
> (beyond hurr durr static linking sucks why do
> you use it; i know, Ulrich)
Now that is a separate question. I believe you can get most of
the benefits of static linking by linking statically to everything
_except_ libraries like libc; libc has a very stable ABI so linking
dynamically to it is just as good (better, actually) if you are
careful about not linking to too-new symbols.
See also "2.22. Even statically linked programs need some shared
libraries" in the glibc FAQ.
Hope that helps,
Jonathan