Date: Mon, 13 Mar 2006 03:15:59 +0900 From: Hajimu UMEMOTO <ume@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: current@freebsd.org Subject: Re: RFC: Symbol versioning for libc Message-ID: <yge7j6zr0kg.wl%ume@mahoroba.org> In-Reply-To: <Pine.GSO.4.43.0603110141570.1515-100000@sea.ntplx.net> References: <ygeacbyqg78.wl%ume@mahoroba.org> <Pine.GSO.4.43.0603110141570.1515-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
>>>>> On Sat, 11 Mar 2006 02:06:39 -0500 (EST)
>>>>> Daniel Eischen <deischen@freebsd.org> said:
deischen> bind8? We have bind9 in the contrib tree; don't you want that?
deischen> Any advantage to making a separate libresolv? But I digress...
Yup, I meant the resolver in BIND9.
Since our resolver is tightly integrated in libc, it is hard to simply
separate it to libresolv. Further, our resolver has many changes.
So, we cannot just replace our resolver to BIND9's one.
However, since res_sendsigned(3) uses MD5 functions, it is hard to
include it without having MD5 functions in libc. So, I'll not merge
it into libc.
And, res_update(3) in BIND9 is not binary compatible with our
res_update(3). So, I'll leave our res_update(3) as is. Since,
res_update(3) is not essential part of resolver, I think that it
should be removed from libc in the future.
So, it may better to have libresolv for such functions.
deischen> Yes, but I was thinking we might need to bump libc version number
deischen> once we enable symbol versioning, so you can probably remove the
deischen> compat stuff anyways.
Okay, thanks.
deischen> The problem with not bumping libc version number is that -stable
deischen> is going to have libc.so.6 also, and any applications you build
deischen> on -stable won't have bindings to versioned symbols. If there
deischen> are no bindings to versioned symbols, the application uses the
deischen> default symbols. When we enable symbol versioning, the default
deischen> symbols will always be the latest (newest) symbols. So if you
deischen> change foo() in -current libc.so.6, that will be the default
deischen> symbol. The old foo() will still remain under an earlier version,
deischen> but newly built applications will use the new foo(). So the
deischen> -stable application on -current's libc.so.6 will use the default
deischen> version of foo() which is not what you want.
deischen> Unfortunately, I don't see any way to avoid it.
I have no idea around here.
> Which timing is better to be done my work before your commit or
> after?
deischen> Thanks for thinking of me :) I'd like to commit my stuff first,
deischen> 'cause it's getting hard to play catch up. Once in the tree,
deischen> you can modify the symbol maps yourself for whatever changes
deischen> you make. I should be ready in a few days; I just have to
deischen> do some testing on the other archs.
It's okay to wait until your work is finished. But, I'm still
wondering if we need to bump symbol version just after your commit.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?yge7j6zr0kg.wl%ume>