require gnu ld for public shared libs?

[Andrew Bartlett]

On Thu, 2012-06-28 at 09:26 -0400, David Collier-Brown wrote:
> On 06/28/2012 04:46 AM, Andrew Bartlett wrote:
> > 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
> > 
> 
> I used to maintain a Solaris-compatible (porting) library on systems
> without built-in linker features for symbol control, and did it with an
> awk script and a yacc grammar.
> 
> The basic idea was to allow anything we'd now consider _PUBLIC_ to be a
> regular function, and any function that wasn't marked as such to be
> demoted to static.

That would require that they all be in the same compilation unit.  Samba
has multiple (hundred) C files in these libraries, of which some
functions we do not wish to expose to callers. 

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