Re: RFC: Symbol versioning for libc

On Sat, 11 Mar 2006, Hajimu UMEMOTO wrote:

> Hi,
>
> >>>>> On Tue, 7 Mar 2006 22:19:22 -0500 (EST)
> >>>>> Daniel Eischen <eischen_at_vigrid.com> said:
>
> eischen> I've been working on symbol versioning libc and have a patch
> eischen> that seems to work.  It's been tested on x86 with build &
> eischen> install world, KDE, mozilla, and firefox, but there may be
> eischen> some problems I haven't found yet.  These would likely result
> eischen> in undefined symbol errors from libraries or applications.
>
> eischen> I'd like to commit what I have to enable wider testing, but
> eischen> turn off symbol versioning by default.  I would also like
> eischen> re_at_ to take a look at the version namespace scheme.  The
> eischen> following was derived from Sun's convention.
>
> I'm working on upgrading the base version of our resolver in libc to
> BIND8's one.

bind8?  We have bind9 in the contrib tree; don't you want that?
Any advantage to making a separate libresolv?  But I digress...

>  We'll have more functions than existing our resolver.
> Though it will rename/remove some functions, we'll have compatibility
> syms for such functions and symbols to provide binary backward
> compatibility.  So, it could be MFC'ed.  I think that such
> compatibility syms can be removed safely using your symbol versioning
> stuff once your stuff is activated.

Yes, but I was thinking we might need to bump libc version number
once we enable symbol versioning, so you can probably remove the
compat stuff anyways.

The problem with not bumping libc version number is that -stable
is going to have libc.so.6 also, and any applications you build
on -stable won't have bindings to versioned symbols.  If there
are no bindings to versioned symbols, the application uses the
default symbols.  When we enable symbol versioning, the default
symbols will always be the latest (newest) symbols.  So if you
change foo() in -current libc.so.6, that will be the default
symbol.  The old foo() will still remain under an earlier version,
but newly built applications will use the new foo().  So the
-stable application on -current's libc.so.6 will use the default
version of foo() which is not what you want.

Unfortunately, I don't see any way to avoid it.

> Which timing is better to be done my work before your commit or
> after?

Thanks for thinking of me :)  I'd like to commit my stuff first,
'cause it's getting hard to play catch up.  Once in the tree,
you can modify the symbol maps yourself for whatever changes
you make.  I should be ready in a few days; I just have to
do some testing on the other archs.

-- 
DE