shlib-compat.h

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> I am not following you at all.  The point here is to handle the cases where
> multiple versions have been rolled into one, and the issue not what the
> name of the set is but whether there is one set or two.  Say a new port
> begins support at GLIBC_2.1; then it should have all the GLIBC_2.0 symbols
> that weren't obsoleted in GLIBC_2.1, but you want all those to go into a
> single version set (GLIBC_2.1) to avoid the overhead of the distinct sets.

There is no overhead (except for perhaps 16 additional bytes in the
.so file).

> then, we need to build the compatibility code because the old 2.1
> releases of this port require that in their ABI, but the symbol must
> be versioned as GLIBC_2.1 instead of GLIBC_2.0 for this platform,
> because that is the version set that the existing binaries are all
> bound to.

No.  The symbol should have the version extension GLIBC_2.0.  This is
just a name.  If you would magically change a symbol which was
introduced in glibc 2.0 and therefore has the extension GLIBC_2.0 to
have the extension GLIBC_2.1 because there is no support for
compatibility with glibc 2.0 then you would have have to rewrite the
Versions file.

Example:

   fgetpos() was introduced in 2.0.  libio/Versions contains fgetpos()
   in the section for GLIBC_2.0 for libc.

   fgetpos() get redefined in glibc 2.2 with an additional entry in
   for fgetpos in section GLIBC_2.2 for libc.

   Now comes a platform without support for glibc 2.0.  With your scheme
   the initial fgetpos() would have the version extension GLIBC_2.1.
   This would mean you would have to move the definition from section
   GLIBC_2.0 to GLIBC_2.1.

   And for what?


The version name extensions are just names.  They describe when the
version was introduced or last changed in glibc.  I could have chosen
completely different names.  In the explanation here I carefully used
the notation glibc 2.0 and GLIBC_2.0 to make the difference clear.

So, just leave it is it is.  There is no measurable difference but
instead you would introduce many more problems.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------