cvs commit: src/share/mk bsd.libnames.mk src/lib/bind config.mk
src/lib/bind/bind Makefile src/lib/bind/bind9 Makefile
src/lib/bind/dns Makefile src/lib/bind/isc Makefile src/l
ru at FreeBSD.org
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:
> > 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
> 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? ;)
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040925/bfb9006c/attachment.bin
More information about the cvs-src