On Mon, Oct 16, 2000 at 08:30:34PM -0400, Ben Collins wrote:
> > Surely there's some other way to work around this, ideally fixing
> > the root cause not having a zillion other packages work around obscure
> > incompatible changes in libc?
> Obviously you don't understand the reason behind this. When daemons are
> running, they carry with them the libc.so.6 that got loaded with it while
> the NSS modules that it uses remain on disk. Now upgrade libc.so.6, and
> the running daemon still has the old one loaded, but the NSS modules are
> new and linked against the new libc.so.6. BOOM. You can't "fix" this, it
> isn't broken. It is inherent in versioned libraries.
It's inherent in the specifics of how glibc split up their library.
If the NSS stuff had been incorporated in the one big .so and that
got loaded up for every program (with all the bloat that would imply),
this wouldn't be an issue. If libc6 was forward compatible with future
NSS modules, it also wouldn't be an issue: when it loaded up the new
modules it'd JustWork, it wouldn't break running programs.
It fundamentally *is* broken: it breaks the semantics of the library when
it gets upgraded. It's not because inetd (eg) is doing something that's
unusual or overly tied to a particular glibc, it's because glibc isn't
taking enough care to ensure that its API is stable during an upgrade.
And note that this is just a software problem: of course it's possible to
fix it. It might be a lot of effort and upstream might not give a damn,
but it's definitely possible.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpwDDn3pr6sa.pgp
Description: PGP signature