What exactly makes tdb2 hard to package (ccan?)

[Andrew Bartlett]

On Thu, 2012-04-12 at 19:49 +0200, Jelmer Vernooij wrote:
> 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?

It doesn't seem to.  If it did, then the patches I proposed are the fix.

I think the reason it doesn't break is that tdb is linked with a version
script, and so the ccan symbols don't leak out.

Andrew Bartlett

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