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

[A Humble Bind User]

[ I'm resending this because my ISP broke my reverse IP lookup functionality -
I didn't seem to get any acknowledgement that this message was
received/processed, so I'm re-sending to be sure.  My apologies if this is
received twice. ]

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=