GMP symbol naming (and the history thereof)?

[Torbjorn Granlund]

Richard Henderson <rth at twiddle.net> writes:

  Excellent.  That's more or less exactly what I want to do.
  
That would be another welcome contribution!

  I believe that IFUNC and the "fallback" fat system can live side-by side,
  sharing most of the actual logic.  The choice of which implementation to build
  into the shared library can be made by configure.
  
Good!

  Fair enough.  While you can't override the mpn routines in libc.so (they're
  hidden), there is a potential issue with static linking.  FWIW, glibc uses
  "__mpn" as the prefix.
  
  FWIW, on another library I wrote recently I used "pfx_" for the external names
  and "PFX_" for the internal names.
  
I suggest that we do it like the following in GMP:

In a static lib, I suppose nothing should change.

In a shared lib, make all symbols by just the logical call name, like
mpn_addmul_1, mpz_mul, gmp_printf, mpn_strangeinternalfunction.  Make
these hidden.  Then for the functions we want to make public, define
aliases to __gmpn_addmul_1, __gmpz_mul, __gmp_printf.

Motivation: This should be link compatible with existing user programs.
Using the plain names internally is a convenience when debugging.

About testing of static vs shared lib.  Currently 'make check' test
either, never both, even if both were built.  I consider this a serious
flaw, since 'make check' gives a false confidence that the library was
not miscompiled.  I would like to change this behaviour.

I realise the 'hidden' project might create some problems for (unit)
testing of internal routines.  I am not sure we do that a lot, except
that tune/speed, tune/tuneup, tests/devel/try surely need access to
everything.  I see two solutions:

1. Possibly have a configure option that disables the 'hidden' stuff.

2. Link these three programs statically.  That's not at all
   unreasonable.

A side note: I think that we should move towards fat binary builds as
the "normal" build.  Our current method of careful compile-time CPU
recognition is better for benchmarking than for the real world.
Ideally, fat builds should be the default for all configs.
Unfortunately CPU manufacturers make CPU recognition difficult.

-- 
Torbjörn