What exactly makes tdb2 hard to package (ccan?)

[Jelmer Vernooij]

On Fri, Apr 13, 2012 at 07:58:39AM +1000, Andrew Bartlett wrote:
> 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.
But AFAIK then wafsamba will assume that you are linking against tdb
(which it know bundles ccan) and thus it doesn't need to link against
ccan explicitly. Am I misunderstanding how things are working?

This is problematic because it means that if the tdb library is
upgraded the ccan functions go away (since their signature changes).

Cheers,

Jelmer