Namespaces and inter-library private symbols

[Greg Hudson]

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."
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.

Symbols used only within a library are easy to handle, and are not at
issue in this thread.

> 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.

The normal method of checking libraries for symbols in autoconf is to
attempt to link a program using that function (un-prototyped) and see if
you succeed, which is equivalent to looking for the symbol in the shared
object's exported symbol table.  There is no easy way to use autoconf
tests which check for a prototype, because there is no portable compiler
behavior for detecting the use of a non-prototyped function.

> 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.