waf: Add possibility to build with system libwbclient/libsmbclient
abartlet at samba.org
Thu Apr 19 20:02:17 MDT 2012
On Thu, 2012-04-19 at 17:04 +0200, Andreas Schneider wrote:
> On Thursday 19 April 2012 15:37:41 you wrote:
> > I know it's difficult, but with this (required) patch the hope of
> > libwbclient being shared with s3 and s4 goes away. Additionally, not
> > only has the default path for where winbindd is changed, but the
> > protocol has also changed - so a master libwbclient just isn't going to
> > work for a 3.6 winbind, and likewise a 3.6 libwbclient won't work with a
> > master winbind.
> > Given all this, does using a system libwbclient ever make sense? It
> > certainly is important not to disrupt the things that are linked to the
> > libwbclient on the system (login tools in particular), but the right way
> > to do that is to make these libraries private where public use is not
> > wanted.
> > I therefore propose the attached patch, to allow you to force a 'public'
> > Samba lib to be private, so it won't need to be installed in the main
> > system namespace, and can just be like any other internal part of Samba.
> > Please let me know if you think this solves your issue,
> I think if libwbclient is really incompatible with other winbind versions,
> then we need to make it private as long as Samba3 and Samba4 coexist in an
> I'm fine with that.
A corrected version of this patch is now in the tree. Please let me
know if this would allow us to then remove the ability to use the system
library versions of libsmbclient and libwbclient.
For libwbclient, the only other plausible use case would be to build
against a likewise libwbclient, but I would only like to enable that
option once someone shows that the likewise libwbclient does indeed
support the operations used by smbd. We would also (to match Volker's
point that libwbclient and winbindd need to be in the same package) to
disable the internal build of winbindd.
Additionally, we would need to change our code to refer to libwbclient.h
as a system header. Currently our code calls:
This would dangerously mix our internal header with a non-Samba system
libwbclient, which would be a very bad idea.
For libsmbclient, it seems that unless you plan to test the system
libsmbclient using the Samba 4.0 smbtorture and other test utilities,
that using only the internal (private) libsmbclient would avoid an
otherwise unnecessary dependency between a Samba 4.0 package and the
system Samba 3.x
We may need to tweak things a little more, but please let me know if you
think this solves your issues. If so, and depending on the outcome of
our discussions, I'll prepare a patch to remove the system library
checks for libsmbclient and libwbclient.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical