Odd problems trying to make use of libbind as a replacement resolver...

Jason Vas Dias jvdias at redhat.com
Mon Oct 17 14:25:30 UTC 2005


FYI: 
Red Hat Fedora Core(FC) FC-3, FC-4 and Rawhide ( FC-5 )
all ship libbind, in the optional 'bind-libbind-devel' sub-package,
the BIND 8.4.6? resolver library that comes with BIND 9.3.1 / 9.2.5.

But BAD problems result, similar to / including the ones you describe,
if you just 'make; make install' in the default source lib/bind directory, 
because this WIPES OUT your glibc's resolver header files in 
/usr/include/{resolv.h,netdb.h,hesiod.h,netgroup.h,res_update.h,sys/mbuf.h,arpa/{inet.h,nameser.h,nameser_compat.h},net/route.h}

Thus programs will be unable to compile and link with the glibc resolver
(or will get problems if they do), and programs including only the libbind
headers could pick up the wrong headers.

The solution I adopted for the Red Hat bind-libbind-devel package is to
install all the libbind headers under /usr/include/bind .

Then programs can continue to be compiled to use the glibc resolver by default,
and can be compiled to use the libbind resolver by compiling with -I/usr/include/bind
or by prefixing each include of a libbind header with 'bind/' .

Programs such as the default sendmail, PERL, and openldap distributions still have
problems building if bind-libbind-devel is installed, because their build configuration
scripts assume libbind is in the default include path if a link of '-lbind' succeeds,
and attempt to use it in preference to the glibc resolver by default, yet they fail
when linked as the glibc resolver uses different header constants to the libbind resolver.

So the motto is:
NEVER MIX COMPILES AND LINKS BETWEEN libbind AND THE glibc resolver

The glibc resolver as shipped in Linux glibc-2.3 is baselined off the BIND 8.2.3 libbind,
NOT BIND 4.x, with significant changes to improve multithreading and IPv6 support .
Yes, it does need upgrading to support DNSSEC and possibly internationalized domain names,
and work is underway to do this.

Regards,
Jason Vas Dias,
Red Hat BIND package maintainer 

On Sunday 16 October 2005 02:10, A Humble Bind User wrote:
> Cheerio Folks:
> 
> [System details: ia32 Linux 2.4, glibc-2.3.x, gcc-3.4.4 (with stack-protector
> patch), Slackware-origined distributions]
> 
> If what I'm attempting to do is "stupid" or impractical, feel free to let me
> have it with both barrels.
> 
> In the course of freshening my various servers' infrastructures, I am becoming
> increasingly uneasy about using the "old" libresolv which comes as a part of
> glibc. (2.3.1-2.3.2 in my case)
> 
> I'd really like to link my various libresolv-using apps against something more
> modern, current, and easily upgraded (glibc upgrades fill me with terror). 
> I've built BIND-9.3.1 with the following option:
> 
> CC=gcc-3.4 CFLAGS='-O2 -fomit-frame-pointer -march=pentium4 \
> -mtune=pentium4 -s -fstack-protector' LDFLAGS=-s ./configure \
> --with-openssl=yes --enable-largefile --enable-libbind \
> --prefix=/usr --sysconfdir=/etc --localstatedir=/var/run/named \
> --with-libtool
> 
> This installs libbind and libbind9 nicely into /usr/lib, along with the
> relevant include files.
> 
> I build openssl with threads + shared library support as well as
> static+no-threads, in the standard way (and with the same exact compiler). 
> That is, my static openssl libs have no threading support, and the shared ones do.
> 
> Here come the problems:
> 
> When I try to build OpenSSH 4.2p1 against libbind instead of libresolv, I get
> the following errors (the first line is actual compiler command issued):
> 
> >>>>>>>>>>>>>>
> 
> gcc-3.4 -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o
> sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/lib  -s -static -lssh
> -lopenbsd-compat -lpthread -lbind -lcrypto -lutil -lz -lcrypt
> 
> /usr/lib/libbind.a(irs_data.o)(.text+0x2a9): In function `__res_state':
> : multiple definition of `__res_state'
> /usr/lib/libpthread.a(errno.o)(.text+0xc0): first defined here
> 
> /usr/bin/ld: Warning: size of symbol `__res_state' changed from 84 in
> /usr/lib/libpthread.a(errno.o) to 35 in /usr/lib/libpthread.a(errno.o)
> 
> /usr/lib/libbind.a(irs_data.o)(.text+0x2cc): In function `__h_errno_location':
> : multiple definition of `__h_errno_location'
> /usr/lib/libpthread.a(errno.o)(.text+0x60): first defined here
> 
> /usr/bin/ld: Warning: size of symbol `__h_errno_location' changed from 84 in
> /usr/lib/libpthread.a(errno.o) to 36 in /usr/lib/libpthread.a(errno.o)
> 
> <<<<<<<<<<<<<<
> 
> Questions: 
> 
> 1. Should I have my applications #include a different resolv.h?  I'd thought
> that the libbind was designed as a drop-in replacement for the "traditional"
> resolver libraries often shipped with glibc and friends?  SSH is not
> "threaded", but rather, I suspect the threading import is pulled in by the
> libbind library (irs_data.o and gai_strerror.o).
> 
> 2. Should I build a "special" libbind without threading support to solve this
> problem?  I build a non-threaded OpenSSL library already [in its static
> incarnation] (for extra speed, as Apache 1.3.x is not a threaded application)...
> 
> 3. This error seems to point out that it's impossible to mix pthreads
> applications and libbind at all, since pthreads is built with __res_state and
> __h_errno_location defined differently.  What would be a "correct" solution
> here?  Recompile pthreads against libbind's headers, and make a separate version?
> 
> 4. When I build ssh in SHARED linkage mode, i.e:
> 
> gcc-3.4 -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o
> sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/lib  -s -lssh
> -lopenbsd-compat -lbind -lcrypto -lutil -lz -lcrypt
> 
> There are no errors, and the resulting binary (appears) to function correctly
> - it correctly resolves every hostname I've tested it with, and it pulls SSHFP
> records fine as well.
> 
> I don't trust it however... given the fact that there is a mismatch of symbols
> between the phtread's and libbind's perspective.  Is it possible that the code
> within the pthread library that has the offending mismatch is never "imported"
> by anything, hence, not a problem in this instance?
> 
> Thanks for any clues you folk can provide,
> 
> =R=
> 
> 
> 



More information about the bind-users mailing list