waf: Add possibility to build with system libwbclient/libsmbclient

[Andreas Schneider]

On Wednesday 18 April 2012 10:37:00 Andreas Schneider wrote:
> On Wednesday 18 April 2012 18:08:13 you wrote:
> > Andreas,
> 
> Andrew,
> 
> > Is there any chance you could give me that chance?  My work pattern
> > gives me great flexibility for review, and in most cases it would be
> > just seeing them by e-mail over the course of my working day would work.
> > It shouldn't put you too far behind, and give me a good chance to
> > provide feedback.
> 
> that's why I contacted you yesterday. I thought you are more or less fine
> cause you didn't say I should wait and you want to disuss this today. Sorry
> if you did and I didn't recognize it.
> 
> > The libwbclient build is a bit interesting it seems, as we have not had
> > a proper version before.  However, Samba4-s3fs strictly depends on the
> > version 0.8 in master (for IDMAP_BOTH support, I may need to bump the
> > version to reflect my changes).  That is, it won't work with just any
> > 'version 0' libwbclient.
> > 
> > For my part, I'll update the version number in the libwbclient header,
> > but the goal Simo shared with me of using the libwbclient from 3.6
> > simply won't work.
> > 
> > On libsmbclient, I wonder if we can find a less intrusive solution to
> > your concerns.  I understand that you want to be able to build packages
> > against master's libsmbclient, but then have the user install the 3.6
> > libsmbclient, and not have the linking fail due to the upgrade to
> > version symbols.  Is that the issue, or have I misunderstood it?  It
> > seems a fairly niche use case, but perhaps I don't fully understand the
> > combinations you propose to support.
> 
> KDE, Gnome and other components link against libsmbclient and libwbclient.
> This is for smb:// support or pam_winbind/winbind support in the login
> managers.
> 
> Samba4 introduced symbol versioning, which is a good thing but as Samba 3
> with autoconf didn't have it and all these other components link against
> it. I can't simply replace them. Adding symbolversioning is a major change
> and we should probably increase the so version number for that.
> 
> Alexander and I have tried to solve this issue in serveral ways but this is
> the only way which is working.
> 
> > (I realise how this could have been a bigger issue before the dependency
> > was trimmed down to just smbget and our torture tools)
> > 
> > If the symbol versions are such a great issue, would it not be simpler
> > to just turn symbol versions back off?  I only added them recently, they
> > can be (optionally) disabled if they cause that much trouble.  For my
> > part, I'm concerned about how many additional options we both want to
> > support and test in the long term, where the use case is so far only
> > defined as transitional packaging need for Red Hat.
> 
> I think that symbol versioning is good and we shouldn't turn it off, but
> maybe it is needed for libsmbclient and libwbclient.

I've read drepper his dso paper again and looked at what I do in libssh. If 
you remove the symbol name from the vscript for libsmbclient and libwbclient 
it should work.

smbc_init_context != smbc_init_context@@SMBCLIENT_0.1.0

So if you remove SMBCLIENT_0.1.0 from the vscript it should work.


	-- andreas

-- 
Andreas Schneider                   GPG-ID: F33E3FC6
www.cryptomilk.org                asn at cryptomilk.org