shared libs without linker scripts?
idra at samba.org
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 samba.org> 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
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'.
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
More information about the samba-technical