Date: Sat, 11 Mar 2006 02:06:39 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Hajimu UMEMOTO <ume@freebsd.org> Cc: current@freebsd.org Subject: Re: RFC: Symbol versioning for libc Message-ID: <Pine.GSO.4.43.0603110141570.1515-100000@sea.ntplx.net> In-Reply-To: <ygeacbyqg78.wl%ume@mahoroba.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 11 Mar 2006, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Tue, 7 Mar 2006 22:19:22 -0500 (EST) > >>>>> Daniel Eischen <eischen@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@ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0603110141570.1515-100000>