What exactly makes tdb2 hard to package (ccan?)

Andrew Bartlett abartlet at samba.org
Sun Apr 15 16:22:48 MDT 2012


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.

And this is how the .pc file template is:

Name: tdb
Description: A trivial database
Version: @PACKAGE_VERSION@
Libs: @LIB_RPATH@ -L${libdir} -ltdb
Cflags: -I${includedir}
URL: http://tdb.samba.org/

I can't see how, when building against a system tdb2, that we would have
any indication that ccan was involved at the dependency layer, and at
the symbol layer, the symbols are hidden by the linker script.

> 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.  

Andrew Bartlett

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




More information about the samba-technical mailing list