Re: shlib-compat.h

[Roland McGrath <roland at frob dot com>]

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

That is just not true.  There is _dl_check_map_versions, called on each
object loaded, that does work linear in the number of version sets.  Then
there is also little bit more link-time overhead, a little bit more space
used not only in the .so file but in each executable that gets its symbols
bound to two distinct version sets, the packaging systems now grok version
sets and so this produces another package dependency token and whatever
little overheads that entails in the packaging system, etc, etc.

> 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.

You seem not to have understood what my script changes do.  I thought I had
explained it and had the impression that other people were clear on it, but
now there is some confusion.  This rewriting of the version scripts is
exactly what my changes to versions.awk do automatically; the Versions
files remain as they are, but the generated *.map files have the version
renamings applied.  Please just look at an example by editting your
shlib-versions file so it uses the new features and then starting a build
to see what the *.map files look like.

> 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?

1. That there be one fewer version set in each .so, with all the associated
   overheads.

2. For anyone looking at the objects, it more accurately reflects how many
   distinct ABIs there actually are being supported by those objects.

> 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.

Indeed the names are just names, and the content of the names does not matter.
But it *is* meaningful to have two distinct version sets instead of one,
and in the cases we are talking about it is desireable to have only one.

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

You can call the difference small, but it is clearly measurable.
I believe we have now addressed all the problems that have arisen
(once things are all converted to use compat_symbol).