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

Rusty Russell rusty at ozlabs.org
Sat Jun 30 00:37:12 MDT 2012


On Thu, 28 Jun 2012 10:35:53 +0200, Jelmer Vernooij <jelmer at samba.org> wrote:
> 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:
> > > > 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?

Sorry!  I somehow missed this part of the thread.  Then I mistook
silence for assent, and committed it :(

Andrew ping me suitably annoyed (thanks!).  Reversion to a library
going through autobuild now.

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

Ok, I missed the use of the linker scripts to play with visibility
entirely.  I've now spent an hour reading the code and various info
files.

One thing that bothers me: the wildcards in SAMBA_LIBRARY's abi_match
are *almost* redundant; we could generate an actual list for the version
script from (simplistic) parsing of headers (and verify it against nm on
platforms where we *do* support __attribute__((visibility))).

It means we could choose to make private libaries use symbol hiding too,
which would be a bit better defined.

And that, in turn, would allow things like samba-util and ccan be
subsystems, meaning we only ever link in the parts we actually use
(esp. if I can get -ffunction-sections and --gc-sections working
reliably, then it'll be at function granularity, not file granularity).
On some configurations, this may be a win.

(Note: _PUBLIC_ isn't quite a complete replacement for abi_match: you
can't mark a variable with a visibility attribute.  tdb needs this for
tdb_null, so that would need _PUBLIC_DATA_ too).

Thoughts?
Rusty.


More information about the samba-technical mailing list