What exactly makes tdb2 hard to package (ccan?)

[Andrew Bartlett]

On Mon, 2012-04-16 at 00:44 +0200, Jelmer Vernooij wrote:
> On Mon, Apr 16, 2012 at 08:22:48AM +1000, Andrew Bartlett wrote:
> > On Sun, 2012-04-15 at 15:36 +0200, Jelmer Vernooij wrote:
> > > On Fri, Apr 13, 2012 at 07:58:39AM +1000, Andrew Bartlett wrote:
> 
> > > > 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?
> 
> > I don't see how that would happen, as this is how the dependencies are
> > declared:
> 
> >         if not bld.CONFIG_SET('USING_SYSTEM_TDB2'):
> >             bld.SAMBA_LIBRARY('tdb',
> >                               SRC,
> >                               deps='replace ccan',
> 
> > That is, the ccan dependency is only entered into our processing if we
> > are NOT using a system TDB2.
> 
> Hmm, I guess perhaps it's the implied_libs attribute that does provide
> the behaviour I was talking about?

Yes, internally to a top level samba build we get into trouble if ccan
is made a builtin library, and becomes implied as available via tdb2
(the linker script then hides the symbols).  For that reason, it isn't
set up that way (at the top level, it is a 'bundled' library instead).

In short, there within a single build there is a behaviour like this,
but it has already been worked around.  I believe the patches I proposed
provide an additional option in continuing to build if ldb ever directly
requires ccan.

> > > This is problematic because it means that if the tdb library is
> > > upgraded the ccan functions go away (since their signature changes).
> > It certainly would be if that was the case.  
> In that case I'm surprised by the difference in behaviour (missing
> symbol errors building samba3) I was seeing when linking against a
> system ldb without tdb2 support. I don't really see why that would be
> happening?

Can you still reproduce this after your commit:

commit 26d68c3c288195cfc152915dede47d505bd30b1d
Author: Jelmer Vernooij <jelmer at samba.org>
Date:   Wed Mar 14 14:30:50 2012 +0100

    samba3util: Add ccan to dependency list now that str_checksum() uses
a ccan function.
    
    Autobuild-User: Jelmer Vernooij <jelmer at samba.org>
    Autobuild-Date: Wed Mar 14 17:55:51 CET 2012 on sn-devel-104

> Related to that, do we handle the case properly where the system ldb
> is built against tdb1 but samba is using tdb2 or vice versa?

It seemed to.  I tested this in autobuild.py, by patching the
samba4-libs target to so it would build tdb1, ldb against tdb1, and then
tdb2 internally.  You could also build tdb2 and then use that as a
system tdb I suppose.

The reason I set up autobuild.py with the samba4-libs target was to
explore these assumed failure paths in a reproducible way.  If you can
reproduce the failures you see there, then it will be much easier to
pinpoint and reproduce any issues you continue to see. 

I'm still not happy with the situation with tdb2, but I want to have
tdb2 stay or fall on the most difficult technical issues, not build
system issues alone.

Thanks,

Andrew Bartlett

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