Re: shlib-compat.h

[Roland McGrath <roland at frob dot com>]

> I don't think is needed or wanted.  This would mean we cannot use the
> Versions files since they record the version under which a symbol is
> available.
> 
> There is nothing wrong with having the version name GLIBC_2.0 even if
> the arhitecture was not support in glibc 2.0.  GLIBC_2.0 is just a
> name.

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.
Then comes along a change as in your example, where a GLIBC_2.0 symbol is
first obsoleted by a new GLIBC_2.2 symbol; 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.