require gnu ld for public shared libs? (was: Re: code duplication in ccan)

[Andrew Bartlett]

On Thu, 2012-06-28 at 10:35 +0200, Jelmer Vernooij 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:
> > > > > 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.

This is what I would like to do for 4.0.  That is, we only produce
public shared libs when we can hide symbols.  Currently that would mean
gnu ld. 

Andrew Bartlett

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