libbind vs. libc & libresolv problems

Adam Tkac atkac at redhat.com
Mon Apr 21 11:41:03 UTC 2008


On Mon, Apr 21, 2008 at 11:42:10AM +0100, Andrew Haley wrote:
> Adam Tkac wrote:
> 
> > with https://bugzilla.redhat.com/show_bug.cgi?id=441429 this problem
> > became serious. We have two DNS resolver related libraries - libbind
> > from ISC on the one side and on the other side libc + libresolv from
> > GNU libc. Both libraries contains same symbols, does same work but
> > GNU libc implementation hides some symbols whose are sometimes needed
> > and this is reason why people linking against libbind (GNU libc is
> > stripped libbind source). Bug written above is one example that this
> > situation has to be solved. When program is linked against NSS and
> > also against libbind for example (because glibc doesn't provide such
> > interfaces) all gets broken because both libraries have same symbols
> > but uses different structures. Best fix is agreement between ISC and
> > GNU libc upstreams who will use that symbols and who will rename them.
> > I know this is only dream and it will take very long time (I'm sure
> > ISC will never change libbind and change in glibc is also nearly
> > impossible). So there are two ways how solve this problem - make
> > needed symbols from glibc public and don't link anything against
> > libbind or drop resolving support from libc and link all against
> > libbind. I vote for libbind as default resolver library because
> > maintenance cost of unsupported code in glibc downstream is bigger
> > than cost of stripped version of glibc. Any hints and ideas around
> > this problem are welcomed. What's your opinion?
> 
> What does libbind do that libresolv doesn't?  In other words, why would
> an application writer prefer to link against libbind?
> 

Generally always when you want more DNS information than A/AAAA/PTR
records. From latest issues I remember that bitlbee finds jabber
servers from SRV records and bug written above needs it for DDNS
updates.

Adam

-- 
Adam Tkac, Red Hat, Inc.




More information about the fedora-devel-list mailing list