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

[Mark Andrews]

> 
> > 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.
> 
> Ah, that's interesting...
> 
> > 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
> 
> Oh dear, yes... 
> 
> > So the motto is:
> > NEVER MIX COMPILES AND LINKS BETWEEN libbind AND THE glibc resolver
> 
> I'm fine with that, really.  My particular problem was that something like
> pthreads had some linkage with libresolv, which meant any multi-threaded
> library would lock me into libresolv unless I rebuild all dependents w/o
> threading support.  This isn't too onerous or painful really, as many
> workhorse UNIX tools aren't threaded at all (sshd, apache-1.3, sendmail,
> uw-imap, etc).  

	Well build a non-threaded version of libbind.

		cd lib/bind
		make distclean
		sh configure --disable-threads
		make depend
		make
		make install
 
> I already segregate OpenSSL builds, and up until semi-recently, was content t
> o
> let the "divide" be shared versus static, as the really security/performance
> conscious things I build statically (on Intel this returns a precious registe
> r
> to common use).  Sure, it's an incremental improvement, but these increments
> do add up (the threaded code exacts a small performance penalty as well).  Bu
> t
> this is turning out to be insufficient.
> 
> > 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 .
> 
> That doesn't sound too bad, then.
> 
> > Yes, it does need upgrading to support DNSSEC and possibly
> > internationalized domain names, and work is underway to do this.
> 
> Heh, well, that's overdue.  I wonder if it'd be possible convince Herr Dreppe
> r
> to bring some harmony in libresolv with current "modern" sub resolver
> libraries, even if it's impossible or impractical to keep it "isolated" so
> that upgrading it isn't onerous.  As it is, at least pthreads seems to be
> compiled with libresolv's constants/etc.
> 
> I appreciate your informative reply.
> 
> =R=
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org