Namespaces and inter-library private symbols

[Nicolas Williams]

On Fri, Nov 13, 2009 at 12:17:46PM -0500, Greg Hudson wrote:
> On Fri, 2009-11-13 at 11:43 -0500, Nicolas Williams wrote:
> > Are there symbols which must be exported but aren't public?
> 
> Uh, yes.  The subject of this thread is "inter-library private symbols."

In my defense, I hadn't finished my morning coffee :(

> The opening message of this thread lists numerous examples of non-public
> libkrb5 symbols used by other parts of the tree.  We have dozens and
> dozens of cases where we currently do this.

Can you eliminate them?

> > It depends on the autoconf test.  If it's looking only for a symbol in a
> > shared object's exported symbol table, then yes, autoconf will find it,
> > but any source code actually trying to use it will fail to compile.
> 
> Source code typically does not fail to compile when using a
> non-prototyped function; at most, you generally get a warning, and often
> only with certain compiler flags.

Sorry, I think I'm assuming C99 too much.  But you could require C99...

> > The accessor is important for plug-in access (to public and private
> > interfaces both) as a way to avoid DLL hell.
> 
> The accessor is only used for private interfaces, and use of the
> accessor begins by invoking a private libkrb5 function
> (krb5int_accessor), so I believe this explanation is incorrect.

Why would the accessor have come to happen if there was already a
convention for private symbols?  I glanced last week and IIRC I saw only
accessor uses by plug-ins.  DLL hell avoidance immediately came to mind.
I think it's the most natural explanation.  You might have to ask
whoever added the accessor though.

Nico
--