shared libs without linker scripts?

simo idra at
Fri Jun 22 17:34:33 MDT 2012

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 to see what libs use it.

I think concealing symbols is available only when using gnu tools in the
autoconf build.

In the waf build we use the symbol versioning facility you know about, I
do not know how it is done for libsmbclient, I hope it uses the public
header file as the reference.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list