What exactly makes tdb2 hard to package (ccan?)
jelmer at samba.org
Sun Apr 15 16:44:28 MDT 2012
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
> if not bld.CONFIG_SET('USING_SYSTEM_TDB2'):
> 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?
> > 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
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?
More information about the samba-technical