Re: compatibility woes

graydon hoare <graydon@xxxxxxxxxx> writes:

> hi,
>
> two things I need to point out wrt compatibility, because they are
> somewhat important:
>
>   1. fedora core 1 and debian both have toolchain bugs related to
>      static linking; having discussed this with the maintainers I am
>      increasingly thinking they wish to not support any concept of
>      static linking at all, in the future.

True for glibc, as far as I can tell.  A similar situation will be
found on Solaris, HP-UX, and recent FreeBSD, and those are only the
ones I know about personally - I would expect it to be a
near-universal trend among libc authors.

>   the implication is that the glibc API is "more stable" than the
>   kernel ABI (amazingly)

This is an oversimplification.  Old kernel ABIs keep working, but
glibc goes to heroic lengths to transparently migrate binaries to new
kernel ABIs.  Such as a completely new implementation of POSIX threads
(in kernel 2.6/glibc 2.3).

>   and glibc continues to do NSS-related dlopen()'s for many
>   functions,

right, this is by design.

>   so there seems really to be no point to fighting this issue any
>   further. I will stop doing fully-static builds shortly, and move
>   to mixed builds (keeping lib3rdparty.a, but dynamically linking to
>   libc). I haven't decided how to handle the non-header parts of
>   boost yet, but perhaps they can be folded into our sources.

I think this is the right move, but you may also wish to consider
using a C library deliberately designed for static linkage, such as
uclibc.

zw