Subject: bin/10651: usr.sbin/bind/named will not link statically
To: None <gnats-bugs@gnats.netbsd.org>
From: None <cgd@sibyte.com>
List: netbsd-bugs
Date: 07/21/2000 13:36:16
>Number:         10651
>Category:       bin
>Synopsis:       usr.sbin/bind/named will not link statically
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 21 13:37:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Chris Demetriou
>Release:        NetBSD-current as of mid-June, 2000
>Organization:
>Environment:
mostly irrelevant.  Cross-compiling (and need to link statically),
but others have verified similar problem with very current sources
in native compilation envionment (linking statically).

>Description:
usr.sbin/bind/named will not link statically.  This is not only
an annoyance for people who want (or need) to link the code statically,
but is also an indication of probable bugs in the code.

the symbols that end up being multiply defined are:
	__dn_comp
	__dn_skipname   
	__putlong  
	__putshort
	__res_dnok  
	__res_hnok
	__res_mailok 
	__res_ownok
	__res_randomid
	_getlong   
	_getshort 
	_res
	inet_addr 

It should be obvious why this is actually a potentially serious
problem.  In case it's not: Something (in libc or elsewhere, e.g.,
the main program) is causing the conflicting libc routines to be
pulled in.  This is often an indication of the fact that both
sets of routines 'want' to be used.  If in fact they are both used
(in a dynamically linked binary) lossage will almost certainly result.
So, it's a serious problem for dynamically linked binaries too
(and arguably a bug that the linker doesn't warn about it for them.)

>How-To-Repeat:
cd usr.sbin/bind/named && make LDSTATIC=-static
(or similar).

notice resulting problems.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: