Richard Henderson <r...@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 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
