shared libs without linker scripts?

[simo]

On Sat, 2012-06-23 at 12:44 +1000, Andrew Bartlett wrote: 
> 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. 

Again I am not sure what you mean by safe, exposing symbols can cause
symbols clashes, this is an inherent issue with C as C doesn't have a
namespace.
In order to reduce chance of clashes people tend to create a namespace
by pre-pending a common prefix to public and private functions and where
possible use exports lists/versions scripts to reduce the amount of
symbols exposed.

But the fact internal symbols may be visible is not inherently an unsafe
condition.

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

Yes libwbclient was supposed to be very public and ABI stable and so was
built to minimize issues.

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

All non-static symbols (functions and variables names) would be visible
normally.

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

What should we stop exactly ?

Simo.

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