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

[Jelmer Vernooij]

On Thu, Jun 28, 2012 at 06:14:44PM +1000, Andrew Bartlett wrote:
> On Thu, 2012-06-28 at 09:53 +0200, Jelmer Vernooij wrote:
> > 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?

> This is what I was trying to discuss with Simo.  I would really like to
> get this right, given the explosion of libraries we are about to
> unleash, as well as changes like this. 
Same here.

> I'm not entirely sure where the _PUBLIC_ decorators fit into this, but
> it seems to me that the only thing we use and support in this area is
> gnu ld version scripts, and then we have full versions and (as I
> understand it) a restricted set of exported symbol (based on the regex
> in the wscript file). 

Being able to rely on always hiding private symbols would be great.
Unfortunately we can't do this on all the platforms we want to
support.

Another option is to require that we can make symbols private if the
user wants to use system installations of e.g. tdb and talloc. This
is a bit of a compromise seems like the most reasonable solution to me.

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/506ded63/attachment.pgp>