cvs commit: src/share/mk src/lib/bind src/lib/bind/bind Makefile src/lib/bind/bind9 Makefile src/lib/bind/dns Makefile src/lib/bind/isc Makefile src/l

Ruslan Ermilov ru at
Fri Sep 24 23:03:43 PDT 2004

On Fri, Sep 24, 2004 at 10:14:32PM +0000, Bjoern A. Zeeb wrote:
> On Fri, 24 Sep 2004, Ruslan Ermilov wrote:
> Hi,
> >   Log:
> >   Don't expose BIND libraries and their headers to the public by default,
> >   but have a knob (WANT_BIND_LIBS) to build and install them in /usr/lib
> >   and /usr/include.  Rumors are that this may be useful at a later point,
> >   let's see.
> can you please be more precise ?
I wasn't aware of this myself when committing this.  It was later pointed
out that lwres library (light-weight resolver library) can replace our
resolver code in libc at some point.  I think once this is done, we'll
just remove this the WITH_BIND_LIBS knob, and only install lwres library,
and make all other BIND library internal without a knob to expose them.

> >   What this really means is that all BIND libraries are now internal to
> >   buildworld (by default, unless WANT_BIND_LIBS is defined), and linked
> >   statically into various BIND executables.
> these days that there is a dynalically linked base system why do it
> the opposite way ? I am just curious ;-)
Why would we need four libraries that aren't otherwise used by anything
else?  Should we also install libgroff, and all internal GCC and BU
libraries?  ;)

> Also I would be interested in the difference of size this makes if you
> build statically vs. dynamically and in both ways install all binaries
> (plus libraries in the dyn case) ?
Enable WITH_BIND_LIBS and check for yourself?  ;)

Ruslan Ermilov
ru at
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the cvs-src mailing list