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: