shared libs without linker scripts?

simo idra at
Mon Jun 25 06:05:54 MDT 2012

On Mon, 2012-06-25 at 11:59 +0930, Rusty Russell wrote: 
> On Sat, 23 Jun 2012 15:25:47 -0400, simo <idra at> wrote:
> > On Sat, 2012-06-23 at 12:44 +1000, Andrew Bartlett wrote: 
> > > On Fri, 2012-06-22 at 21:21 -0400, simo wrote:
> > > > 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.
> Yes.  If you don't have symbol visibility control, you inevitably leak
> some symbols.
> But AFAICT you generally get away with it: if library A and library B
> both contain a 'foo' symbol, A will use A's, and B will use B's.  (Does
> someone have such a system where they can verify?).

Rusty, this is not always true, although the default now (RTLD_LOCAL).

> However, if 'foo' was a symbol which program C used, it could get
> either.

The 'foo' symbol may be used within the whole program by A, B, C usually
when using RTLD_GLOBAL.

> But this just means that you should ensure namespace on
> meant-to-be-public symbols, which you should do regardless.

True, however the worry here is about leaking 'private' symbols, however
even leaking them i not necessarily 'unsafe'.


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