Hi, >>>>> On Sat, 11 Mar 2006 02:06:39 -0500 (EST) >>>>> Daniel Eischen <deischen_at_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 _at_ Internet Mutual Aid Society Yokohama, Japan ume_at_mahoroba.org ume_at_{,jp.}FreeBSD.org http://www.imasy.org/~ume/Received on Sun Mar 12 2006 - 17:16:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:53 UTC