After several hours of patching and hacking and rebuilding I've finally
managed to get BIND-8.3.3 to build statically on NetBSD.

To do so I've basically taken the hack used in the in-tree BIND which
renames several private but global symbols to have a "bind_" prefix so
that they don't conflict with libc symbols that have not been protected
by libc's "namespace.h".

Unfortunately this is far less than ideal as it still results in almost
all of the libc resolver code being pulled in to (courtesy the hesiod
calls in getpwent.o, and the use of getpwnam() in named).  Now so long
as the target system's /etc/nsswitch.conf doesn't use any DNS-related
configuration for the user and group databases, nothing untoward should
happen.  However it's still rather messy and bloatish and far from
elegant.

The same problem occurs when the in-tree named is static-linked too.
(though I think in -current another tweak to the "bind_" hack will be
necessary due to an unprotected gethostbyname2() -- I'm not sure why it
wasn't a problem before, but it was in my build outside the source tree)

I think the better solution would be to include src/lib/libc/include/
namespace.h in the libbind compilation, but doing so properly would
require basesrc to be available on the machine where net/bind8 is built.
I think "namespace.h" is backwards compatible so perhaps it could be
"borrowed" from -current and put in a pkgsrc patch, but I'm not 100%
sure.

Another hack would be to supply a private copy of getpwent.c which did
not attempt to do the NetBSD thing with /etc/nsswitch.conf and then
require the user to always run named as a user listed in /etc/passwd.
The latter is probably what I'll try to do for my production named's.

The ultimate solution may be to resolve the ISC ISR vs. NetBSD nsswitch
conlict.....

I'd appreciate any comments or other suggestions about how to move
towards a more elegant solution....

I'd also like to ask what happens when there are conflicts between
static-loaded symbols and dynamic-loaded symbols.  Are the shared
library versions "safe" and separate -- i.e. still used by the
references within the library while the static versions are used by the
main program into which they're linked?  This is what I'm assuming
happens, and I'm assuming that in the case of named in particular this
duplication won't cause problems regardless of whether the program is
entirely static-linked or not.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>