Symbol hiding and unit tests

[Torbjörn Granlund]

  > The good effects of this are:
  > 1. The symbols cannot be reached from outside of the shared lib.
  > 2. The internal references are resolved at library creation time instead
  >    of at application startup time
  > 3. The internal references do not need an indirection (via a PLT in the
  >    case of functions, or a GOT in the case of data).
  
  > An undesirable effect is that our unit tests can no longer reach
  > __gmpn_toom22_mul of the shared library.  It can still reach it in
  > the static library (as symbol hiding has no meaning there).
  
  > If we don't want to do that, we need to provide a "backdoor" to the
  > internal functions.  We could then provide an alias (using
  > __attribute__((alias(...)))).  This, of course, re-enables user code's
  > access to the same internals.  The other benefit (points 2 and 3) remain.
  
  I believe benefits 2 and 3 are important. If it's not too much
  complicated, I'd prefer to see this "alias" approach first, for the
  functions that we are actually testing. Hiding "most" of the internal
  functions is a good goal.

Unfortunately, it has now become obvious to me that symbol hiding
conflicts with unit testing.  :-(

This can be handled either by

1. hiding (much!) fewer internal symbols, or by
2. linking each unit test to the needed PIC objects instead of the ,so file.

The latter is a major task, but the dependencies could presumably be
done with some clever scripts.

  What about tune/speed and tune/tuneup?

I don't think we need to link those to PIC objects or the full .so file;
static linking is fine.

I now have a messy patch for this thing.  The test suite passes.  It is
rather messy, and will need a cleanup.  Also, I need to make sure it
doesn't break non-standard systems like Windoze and Mac OS X.

-- 
Torbjörn
Please encrypt, key id 0xC8601622