shared libs without linker scripts?

[Andrew Bartlett]

On Fri, 2012-06-22 at 21:21 -0400, simo wrote:
> On Sat, 2012-06-23 at 11:11 +1000, Andrew Bartlett wrote: 
> > On Fri, 2012-06-22 at 19:34 -0400, simo wrote:
> > > On Sat, 2012-06-23 at 08:50 +1000, Andrew Bartlett wrote: 
> > > > On Thu, 2012-06-21 at 22:05 -0400, simo wrote:
> > > > > On Fri, 2012-06-22 at 08:58 +1000, Andrew Bartlett wrote: 
> > > > > > On Thu, 2012-06-21 at 14:22 +0200, Jelmer Vernooij wrote:
> > > > > > 
> > > > > > > Of course, symbol versioning will help you on Linux, but not all
> > > > > > > platforms support symbol versioning.
> > > > > > 
> > > > > > On this, I'm thinking about the broader implications of running without
> > > > > > a version script.  Isn't that what we use to make (eg, as an example
> > > > > > that we know has poor internal namespace control) libsmbclient safe, and
> > > > > > not expose all our internal guts, even on autoconf?
> > > > > > 
> > > > > > That is, can we do any shared libs, on any build system safely without
> > > > > > it?  
> > > > > 
> > > > > Symbol versioning is orthobonal to the export list
> > > > 
> > > > I could only find the build system code for the gnu ld linker script,
> > > > how is the export list specified otherwise?
> > > > 
> > > > I can't see any other mechanism that we use - libsmbclient doesn't use
> > > > _PUBLIC_ decorators either, so I'm genuinely curious how is this being
> > > > done!
> > > > 
> > > > Andrew Bartlett
> > > 
> > > The --version-script flag of the linker is used (check GNU ld docs for
> > > details) to define what symbols to make public, however you do not have
> > > to specify versions, the basics is to provide a list of 'global' symbols
> > > (to be exported) and define every other symbol as local (not exported).
> > > 
> > > In the autoconf build the export script is generated using the
> > > source3/script/mksyms.awk script I believe, and i derived from the
> > > library public header.
> > > 
> > > Search for SYMSEXT in Makefile.in to see what libs use it.
> > > 
> > > I think concealing symbols is available only when using gnu tools in the
> > > autoconf build.
> > 
> > What I'm getting at is this:  Is it safe to produce shared libraries
> > without gnu tools?
> 
> I guess it depends on what you mean by 'safe'.

Exposure of internal implementation symbols in the exported symbols of
the shared library. 

> > If it is not safe in general, is libwbclient simple enough to be an
> > exception?
> 
> An exception for what ?

Compared with our other libraries, libwbclient seems strictly use wbc_
or winbind_ prefixes, meaning that internal symbols are unlikely to
clash with any other implementation of anything.

As a counter-example, without a linker script, do you agree that
libsmbclient would expose all our internal implementation symbols (which
in general are not in a good pattern)?

> > The reason I'm asking is that with Samba 4.0 we are about to have an
> > explosion in the number of public shared libraries.  Following on from
> > the danger in exposing internal symbols, I'm thinking we should restrict
> > the production of public shared libs to systems with gnu ld.
> 
> In general we should avoid making libraries public unless we want to
> maintain a reasonably stable ABI.
> It is not really important to conceal private symbols as long as we have
> only symbols we consider public in the public headers.

OK, but this discussion started because of concerns about exactly this
(exposure of private symbols, ccan in this case), which is why I'm
probing this area.

I am concerned that without linker scripts, that libsmbclient and the
new Samba4 shared libraries might expose internal implementation
symbols, and I'm wondering if we should stop doing that before we
release 4.0.

Andrew Bartlett

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