waf: Add possibility to build with system libwbclient/libsmbclient

[Stefan (metze) Metzmacher]

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.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120418/0f8aefd8/attachment.pgp>