Date:        Tue, 16 Oct 2001 19:41:54 -0700
    From:        Jason R Thorpe <thorpej@wasabisystems.com>
    Message-ID:  <20011016194154.W19512@dr-evil.shagadelic.org>

  | Face it -- it is a problem we have to consider, otherwise you have to
  | deal with frustrated users who have programs break "randomly".  The
  | last thing I want to do is make NetBSD less pleasant from a user/upgrade
  | point of view.

As I understand it, programs wouldn't break randomly - an old binary would
be using an old libc - the same old libc that the binary only library is
using, and everything just keeps on running (provided it is running on a
kernel with the COMPAT option for the old version enabled of course).

It is only newly linked programs that can suffer from the libc version
mismatch problem, right?  Which means there's nothing at all random about it.

There's certainly a theoretical problem that is very difficult to solve here.
And what's more, on some systems (perhaps solarix, aix, hpux, ...) where
users typically get lots of stuff in binary only form, that theory
translates into a major real problem as well.

It isn't clear to me that there's an actual identified real problem for
NetBSD though.

The identified ELF limitation is certainly not a problem that matters,
linking with 2 different libc's wouldn't work.  If I call a function from
libfoo which is documented as returning an error number in errno (probably
just passed back from some sys call it makes) then I'd be kind of surprised
to learn that the errno it set isn't the same errno that my application can
see, because the one it used is one from a different libc than the one I'm
accessing - and they can't just be aliased together, as there's no way the
linker can know that the formats of the two are compatible.

But, aside from qt, are there examples of other binary only libraries (better
examples would be where the chances of getting a recompiled version a tiny),
that are actually used on NetBSD systems, and which need to be used to link
new programs (rather than just to continue to support old ones) ?

If no examples of that can be found, then perhaps sometime fairly soon would
be the time to do all of the libc cleanups that can be imagined, bump the
major number, recompile and bump major numbers on everything else (including
having pkgsrc detect which libc version will be used, and generate the
appropriate bumped, or not bumped, major number for all pkg .so's), and
generally go through all that pain before we do reach the state where a
libc major number bump actually becomes impossible.

Of course, this would appear in a new major release of NetBSD (perhaps
even NetBSD 2) and would be accompanied by warnings that it is not possible
to link apps against .so's compiled on older versions of NetBSD.

I wouldn't recommend doing this very often, but I do think that planning to
do it once (once more), before it is clearly too late (I really doubt that is
now, I suspect there are very few NetBSD users who would be badly treated by
it) is something worth doing - not just to delete all the renaming cruft in
the current libc, but also to provide an opportunity to fix all the interfaces
that currently make any kind of upgrades difficult (like known fixed size
FILE structs, etc).

kre