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

[simo]

On Thu, 2012-06-28 at 18:14 +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. 

The problem is in trying to use symbol hiding to 'resolve' circular
dependency issues that have been 'broken' by simply letting multiple
symbols be hidden.

Don't do that.

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

I prefer manually maintained files, over auto generated .h files from
_PUBLIC_ decorator, mainly because you *really* want doxygen
documentation and you want it in the header file you are going to
install, not in the source code that doesn't get installed.

It also makes it more difficult to break the ABI by mistake (although we
already have checkers for most stuff, so that's not a big deal).

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>