shlib-compat.h
Roland McGrath
roland@frob.com
Tue Mar 21 21:49:00 GMT 2000
> 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.
More information about the Libc-hacker
mailing list