Unit tests of internal functions

[ghudson@MIT.EDU]

We have a bunch of small test programs in the tree, usually with
sources named t_something.c, usually unit-testing an individual
function or small set of functions.

When the function we're unit testing is a non-exported symbol of a
library, we link the test program against the C source file where it
is defined, in addition to (or in some cases of) instead of the
library.  This practices can cause aggravating build system problems,
because the defining C source file may contain references to
non-exported symbols in other files, which may not even be in the same
build directory.

Here are some alternatives under discussion:

1. Just export those symbols, as we do in a number of cases already.

2. Make those symbols available through the accessor.  I would
personally find this annoying, but it's a valid option.  This only
really helps us in libkrb5, not for other libraries.  (We have
libk5crypto symbols available in the accessor, but it's kind of silly
since they currently have to be exported from libk5crypto to
accomplish that.)

3. During make check, build a second version of each shared library
with no restricted export list, and link test programs against that.

4. During make check, build static versions of each library and link
test programs against that.  Zhana raised the objection that shared
libraries should be tested as shared libraries, but I think that's
only important for system tests (like the ones we have in
tests/dejagnu), not unit tests.

Opinions?