waf: Add possibility to build with system libwbclient/libsmbclient

Andreas Schneider asn at cryptomilk.org
Wed Apr 18 05:26:53 MDT 2012


On Wednesday 18 April 2012 11:06:35 Andreas Schneider wrote:
> 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.

I think we have a serious problem here. Lets take smblcient as an example here 
and how it is some.

Assume Samba4 has been released and we have a security problem in libsmbclient 
and fix it and release it. The version was 0.1.0 and it will be 0.1.1.

We will end up with a vscript which only exports version SMBCLIENT_0.1.1 and 
everything which links against version 0.1.0 will not work anymore cause the 
symbols are not there.

It will look for smbc_init_context@@SMBCLIENT_0.1.0 and will not find it. What 
we have now is smbc_init_context@@SMBCLIENT_0.1.1. Cause you don't export the 
symbols from the previous version.

I think there shouldn't be any version information in the vscript at all. I 
don't think we plan to break the API and have a function which different 
prototypes and symbol versioning support. We really don't want to do that 
cause it is a pain.


	-- andreas

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



More information about the samba-technical mailing list