Symbol clash in libsamba-util and libnetsnmp

[Andrew Bartlett]

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
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba