waf: Add possibility to build with system libwbclient/libsmbclient

Wed Apr 18 19:19:38 MDT 2012

On Wed, 2012-04-18 at 15:48 +0300, Alexander Bokovoy wrote:
> On Wed, Apr 18, 2012 at 15:19, Stefan (metze) Metzmacher
> <metze at samba.org> wrote:
> > Am 18.04.2012 13:26, schrieb Andreas Schneider:
> >> 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.
> >
> > That doesn't happen because waf figures out the version the symbol was
> > introduced
> > by looking at the commited ABI files. So
> > smbc_init_context@@SMBCLIENT_0.1.0 will
> > stay even if the version is 0.1.1.
> To summarize IRC discussion the versioning example above does not
> cover case of non-versioned previous symbols. These should be also
> added into vscript so that they stay unversioned forever and only new
> symbols obtain versions per ABI change.
> Right now methods in buildtools/wafsamba/samba_abi.py do not look at
> 'foo.sigs' to produce non-versioned symbols. They need to support
> that. We then can move all symbols which were previously available
> non-versioned in samba3 build of libsmbclient to libsmbclient.sigs and
> add new ones in additional libsmbclient-0.1.0.sigs,
> libsmbclient-0.1.1.sigs and so on.

I'm happy with this, as it would allow switching packages between
otherwise identical ABIs without introducing a build dependency on
packages that later build against these libraries, particularly while we
have the autoconf and waf build. 

However, I would like to explore this in more detail, if you don't mind.
My understanding is that symbol version support was expected to permit
the one-time upgrade to versioned symbols without rebuilding, and if
that doesn't work, I would like to understand why, so we can allow such
an upgrade in future without going back over all this again.

You said on IRC that you have some failure logs that demonstrate this.
I am interested to see them.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org