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

[Andrew Bartlett]

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. 

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

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