Re: shlib-compat.h

[Roland McGrath <roland at frob dot com>]

> I was just converting a file which has a function which is defined for
> 	GLIBC_2.0
> and	GLIBC_2.2
> 
> If now the scripts determine the GLIBC_2.1 is the latest version
> needed support in the libc then
> 
> 	#if SHLIB_COMPAT (libc, GLIBC_2_0)
> 
> will fail although the 2.0 version of this function is used in version
> 2.1 of the library.

I've just checked in a change whereby this would be done:

	#if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_2)

This indicates that GLIBC_2.0 introduced this code, and GLIBC_2.2 obsoleted
it.  So, if the version GLIBC_2.0 is mapped to is earlier than GLIBC_2.2,
then we need the compat code.  Thus, your configuration where GLIBC_2.0 is
subsumed by GLIBC_2.1 will include this compat code, but a future
configuration where GLIBC_2.0 is subsumed by GLIBC_2.2 (or later) will not.

What's also needed that I haven't done is to replace `symbol_version' with
a macro like the new `versioned_symbol' macro (perhaps `compat_symbol' is a
good name for the new macro), that will use `GLIBC_2_0' for its version arg
and apply the VERSION_* renaming macros.  That way, in your example the
compatibility code will be defined, and the symbols will be assigned
version GLIBC_2.1 instead of GLIBC_2.0.