Re: Versioned symbols for 3.0?

[Behdad Esfahbod <behdad esfahbod gmail com>]

On 05/18/2010 12:50 PM, Patryk Zawadzki wrote:
> 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:
> 
> libc.so.6(GLIBC_2.0)
> libc.so.6(GLIBC_2.1)
> ...
> libc.so.6(GLIBC_2.12)
> 
> Now if a package uses a symbol from a versioned interface, rpm will
> automatically add "Requires: libc.so.6(GLIBC_2.6)" 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.).

Understood.  And I have to agree, it's a desirable feature.

If we autogenerate the version script, I think Matthias can be bribed into
accepting it (I know I'd welcome that in pango).  Though we probably first
need a way to remove the galias hacks.

Ryan, what's the summary of the alternate approaches there?  Does Link-Time
Optimization that went into gcc 4.5 make any difference?

Cheers,
behdad