[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] compatibility woes
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] compatibility woes |
Date: |
Thu, 27 Nov 2003 11:27:25 -0800 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
graydon hoare <address@hidden> 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