code duplication in ccan (was: Re: snprintf on SunOS)

[Jelmer Vernooij]

On Sat, Jun 23, 2012 at 09:07:21AM +0930, Rusty Russell wrote:
> On Thu, 21 Jun 2012 14:22:37 +0200, Jelmer Vernooij <jelmer at samba.org> wrote:
> > On Mon, Jun 18, 2012 at 11:04:48AM +0930, Rusty Russell wrote:
> > > On Sat, 16 Jun 2012 10:28:46 +0200, Jelmer Vernooij <jelmer at samba.org> wrote:
> > > > Hi Rusty!

> > > Hi Jelmer!

> > > > > Because you'd have to maintain an ABI.  And that would stop us from
> > > > > fixing bugs or removing functions; you really don't want a bag of utils
> > > > > to be a shared library!

> > > > > Or we could keep changing the ABI, making it useless for anyone outside
> > > > > Samba anyway.
> > > > The problem is that in its current form, we already rely on the ccan
> > > > ABI not changing.

> > > > If you have an older version of tdb installed on your system which includes a
> > > > copy of ccan and you build a newer version of Samba, then you end up
> > > > with ABI incompatibilities.
> > > ?????!! WTF?

> > > No, this is *completely* wrong!

> > > Why do you think this?  How would that work?
> > ntdb ships a copy of ccan, which gets built as a shared library.

> Argh, yes the *top-level* build does that.  configure and build inside
> lib/ntdb, and waf gets it right and doesn't try to make ccan a shared
> library or any such stupidity.  Fix below.

> (I wrote an analsyis of -ffunction-sections and --gc-sections here,
> which is perfect for CCAN, but unfortunately that causes ld to segfault
> if we use it for a top-level build!).

> Subject: ccan: we're a subsystem, not a library.

> Don't expose a libccan; it would produce clashes if someone else does the
> same thing.  Just build in the bits we need.

Wouldn't this just cause the same issues? You're still ending up with
two different copies of the ccan symbols on systems that don't have
symbol versioning. Are we actively trying to hide symbols from
subsystems yet?

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120628/79519d51/attachment.pgp>