What exactly makes tdb2 hard to package (ccan?)

[Jelmer Vernooij]

Am 12/04/12 07:04, schrieb Andrew Bartlett:
> On Mon, 2012-04-09 at 21:20 +1000, Andrew Bartlett wrote:
>> On Mon, 2012-04-09 at 11:13 +0200, Jelmer Vernooij wrote:
>>> Am 09/04/12 08:59, schrieb Andrew Bartlett:
>>>> On Thu, 2012-04-05 at 16:08 +1000, Andrew Bartlett wrote:
>>>>> I've been told that the issues with bundled ccan libs are still causing
>>>>> issues for distributors, so I've come up with a patch that I think
>>>>> should help.  I'm doing this so we can separate these issues from any
>>>>> other discussion around tdb2, as I think there are technical build
>>>>> system issues we can address.
>>>>>
>>>>> These patches re-introduce the private library extension (-samba4, -ldb,
>>>>> etc), but only for ccan.  This is on the basis (which I need to confirm)
>>>>> that ccan has no static data that would cause an issue if duplicated.
>>>>> Libraries with important static data like talloc are not renamed, and
>>>>> will deliberately cause a library conflict as pre previous behaviour. 
>>>>>
>>>>> (BTW, Linux distributors should not bundle or distribute libreplace, but
>>>>> instead depend on libbsd). 
>>>>>
>>>>> Please let me know if this helps.  The patches are attached, and in
>>>>> https://git.samba.org/abartlet/samba.git/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/less-ccan-pain
>>>> In order to test this, I added a mode to autobuild that tries to build
>>>> 'distribution style' Samba, that is based on 'system libraries' (in a
>>>> private prefix in this case). 
>>>>
>>>> This should be in master soon, and should help us avoid regressions that
>>>> have often hit distributors and OpenChange.  This patch uses tdb1, as
>>>> this is what all distributors use, so it is an important use case to
>>>> test.
>>>>
>>>> Then, I've then applied the attached patch to test building with tdb2,
>>>> which I was expecting to fail.  It still passes, without any of the work
>>>> I mention above.  
>>>>
>>>> So, I'm a little stumped.  Can someone describe the 'linux distribution
>>>> packaging' failure mode here? (preferably in the form of a patch, so I
>>>> can reliable test it)?
>>> The main issue with tdb2 has been that it caused various kinds of
>>> trouble - various missing symbol errors, concerns about duplicate symbols.
>>>
>>> If I try to build Samba4 without --disable-tdb2 here, I get:
>>>
>>> default/source3/libsmb/smb_share_modes_12.o: In function `smb_name_hash':
>>> /home/jelmer/src/samba/bin/../source3/libsmb/smb_share_modes.c:320:
>>> undefined reference to `hash_any'
>>> collect2: ld gab 1 als Ende-Status zurück
>>>
>>> (My ldb wasn't built against tdb2)
> I've tried reproducing this in autobuild, but can't.  Can you help me
> out?
I think you need build ldb without tdb2 support, not Samba.
>
> Attached are the two patches for the samba4-libs target that I tried to
> use. 


>>> There have been various errors like this in the past; I've fixed a
>>> couple, but presumably there are still some left. I suspect this is due
>>> to the fact that waf thinks that ldb already includes ccan, so it no
>>> longer has to build or link against it itself.
>> Thanks.  I'll test with that and see what I get, hopefully it's just a
>> missing dependency from smb_share_modes to whatever provides hash_any,
>> right?
> BTW, ccan seems to be a smb_share_modes dependency now.
Won't this lead to possible symbol clashes when somebody is building
Samba with a system tdb, which includes its own ccan?

Cheers,

Jelmer


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