Namespaces and inter-library private symbols
Nicolas.Williams at sun.com
Fri Nov 13 12:40:57 EST 2009
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.
More information about the krbdev