waf: Add possibility to build with system libwbclient/libsmbclient

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy