On Wed, 25 Mar 1998, Jonathan Stone wrote:

: >Can't remove them completely from libc now: "binary compatibility."
: 
: Yes we can, when we next bump the libc major number. And we should.

<OPINIONATED RANT MODE>

No, we shouldn't bump the libc major.  Unless you're willing (or the person
who bumps is willing) to make a complete stub library such that v12-libc
programs can make use of new functionality introduced in later versions of
libc 13 (nsswitch? IPv6? The list is big.), that version number should *not*
be bumped, leaving every old binary out in the cold.

I can buy into the libc bumping for an a.out->ELF transition, but as Solaris
showed us, it is perfectly possible to use ELF shlibs on an old a.out
binary.  So what do we do?  Not as difficult as you may think:

- on all platforms, create a short stub library (ELF format) with major
  version 12, which calls the versioned functions in libc 13 using dlfcn()
  (or its equivalent) to find the needed functions.  The v12 library will
  not, of course, be versioned in and of itself, but it needs versioning
  knowledge of ELF in order to know which v13 functions to call.
- on a.out platforms to be transitioned to ELF, give the a.out ld.so enough
  knowledge of ELF to load ld.elf_so as well.  If a need arises to map an
  ELF shlib, redirect the dl*() calls into ld.elf_so.  Therefore both a.out
  and ELF shlibs may be mapped.
- on platforms already ELF, there is no ld.so trickery involved; it is
  already there and only a v12 stub library is needed.

This is information gleaned from poking around in Solaris, and if you find
the right Sun engineer, you may find that it's precisely what Solaris does
when a SunOS a.out binary loads /usr/lib/ld.so, who opens /usr/lib/ld.so.1
(ELF), /usr/4lib/libc.so.1.9 (ELF, though it corresponds to an old a.out
lib), and /usr/lib/libc.so.2.9 (ELF main system libc).

</OPINIONATED RANT MODE>

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)