Re: Versioned symbols for 3.0?

On Tue, May 18, 2010 at 6:32 PM, Behdad Esfahbod
<behdad esfahbod gmail com> wrote:
> On 05/18/2010 12:30 PM, Patryk Zawadzki wrote:
>> As for not wanting to use versioned symbols, could you provide more
>> information why such a decision was made?
> I can't speak for Matthias, but I guess it's because no one pointed out what
> currently-existing problem exactly it's trying to solve.

The most important to us as a distribution is being able to
automatically maintain dependencies for libraries that add symbols
without changing their soname. For example g_malloc_n was introduced
in glib 2.24.

We currently need to manually test each app linked to glib to find the
minimal glib version needed because just depending on the soname is
not enough. We could rely on application maintainers providin correct
versions in the configure files but 1) that's not always the case and
2) glib's very own macros can introduce new dependencies at the
compilation time (for example after we upgraded to glib 2.24
g_malloc_n was introduced to a number of applications that compiled
and worked with older glib releases).

On the other hand we don't have to do this for glibc as rpm
automatically extract interface versions and glibc automatically gets
these provides:

Now if a package uses a symbol from a versioned interface, rpm will
automatically add "Requires:" without us having
to search through the history of API changes. I imagine the same thing
can be done (or already is done) for other packaging solutions (deb,
autopackage, zeroinstall etc.).

The not so important feature is being able to deprecate symbols and
_remove them from the public API_ without breaking ABI. This can be
achieved using the __asm__(".symver ..."); call and aliasing a symbol
under the old name in the old interface version (you still need to
keep the code but you get to keep the ABI).

Patryk Zawadzki

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]