Symbol clash in libsamba-util and libnetsnmp

Andrew Bartlett abartlet at
Tue Apr 15 16:16:38 MDT 2014

On Mon, 2014-04-14 at 16:20 +0200, Bjoern Baumbach wrote:
> Hi!
> We encountered a problem with the memdup() function in the
> libsamba-util. The libnetsnmp provides also an own memdup() function and
> typically this one does not use symbol versioning.
> In this case the libsmbconf prefers the unversioned memdup() instead of
> our own memdup().

> Does anybody know how we can solve this in general? In the case of the
> nss_wins we could reduce the large number of dependencies by using the
> wins-resolving-functionality of the winbind client library.

The issue here is that in order to make libsmbconf build during the
conversion to WAF, we had to set 'allow_undefined_symbols=True' on some
libraries.  Due to the way linker flags are propagated around, it ends
up applying to a very large part of Samba, and occasionally causes this
kind of drama.

If undefined symbol resolution was not permitted, then we would have
bound ourselves to Samba's memdup function due to link-time symbol
version resolution. 

The major loop here is between the loadparm code and the registry code,
due to the smb.conf in registry support.  This essentially involves
making dbwrap_open() and all callers take a struct loadparm_context,
created by loadparm_init_s3(), therefore allowing us to break the loop
(essentially using the plugin pattern to break the loop).

I started on this just to see how hard it could be, but I don't have
time to finish it right now.  I can send you my work in progress if you
are interested. 

Andrew Bartlett
Andrew Bartlett
Authentication Developer, Samba Team
Samba Developer, Catalyst IT

More information about the samba-technical mailing list