-----Original Message-----
From: Bill Hart
Sent: Wednesday, October 17, 2012 5:10 PM
To: mpir-devel ; flint-devel
Subject: [mpir-devel] Symbol clashes between flint and mpir
Hi all,
I am just working on the release of MPIR 2.6.0 and it has been noted
(by Fredrik I think) that there are symbol clashes between the two
libraries. This is not in general a problem if the library order is
correct, but the mistake too easily occurs that the library order is
incorrect. It would also not be a problem if the functions were fully
binary compatible, but this seems to not be the case in at least one
instance, and is not something we want to maintain for the future
under any circumstances.
Below is a list of the functions involved (the list is from MPIR). The
ones with * before their name actually have the same name as the
equivalent flint function:
* fft_split_limbs
* fft_split_bits
* n_revbin
* mpn_normmod_2expp1
* fft_naive_convolution_1
* fft_mulmod_2expp1
* fft_adjust_limbs
mpn_mulmod_Bexpp1_fft
mpn_mul_trunc_sqrt2
mpn_mul_mfa_trunc_sqrt2
* mpn_mul_fft_main
* mpn_mul_2expmod_2expp1
* ifft_butterfly_sqrt2
ifft_trunc_sqrt2
ifft_trunc1
ifft_trunc
* ifft_butterfly
* ifft_radix2
* ifft_negacyclic
* ifft_butterfly_twiddle
* ifft_radix2_twiddle
ifft_trunc1_twiddle
ifft_mfa_trunc_sqrt2
ifft_mfa_trunc_sqrt2_outer
* fft_butterfly_sqrt2
fft_trunc_sqrt2
fft_trunc1
fft_trunc
* fft_butterfly
* fft_radix2
* fft_negacyclic
fft_mfa_trunc_sqrt2_inner
* fft_butterfly_twiddle
* fft_radix2_twiddle
fft_trunc1_twiddle
fft_mfa_trunc_sqrt2
fft_mfa_trunc_sqrt2_outer
* fermat_to_mpz
* mpn_div_2expmod_2expp1
* fft_combine_limbs
* fft_combine_bits
* butterfly_rshB
* butterfly_lshB
* fft_adjust_sqrt2
* fft_adjust
* n_sqrt
* n_precompute_inverse
* n_is_square
* n_preinvert_limb
* n_addmod
* n_submod
* n_mod2_preinv
* n_ll_mod_preinv
* n_mulmod_precomp
* n_mulmod2_preinv
* n_powmod_precomp
* n_powmod2_preinv
* n_powmod
* n_powmod2
* n_gcd
* n_invmod
* n_jacobi
* n_is_pseudoprime_fermat
* n_is_strong_pseudoprime_precomp
* n_is_strong_pseudoprime2_preinv
* fchain_precomp
* fchain2_preinv
* n_is_pseudoprime_fibonacci
* lchain_precomp
* lchain2_preinv
* n_is_pseudoprime_lucas
* is_likely_prime_BPSW
Now, all the functions after the break should have been called
mpir_n_blah right from the start. But they are only used in one file
(that I can see) and so can probably just all be made static. If I
understand the meaning of the specifier correctly, this means the
function is visible in the file (internal translation unit in the
parlance) that it is declared in only. This is what we want for all
the functions after the break.
The fft functions however are more problematic. These probably want to
be maintained as internal functions in MPIR to be used elsewhere as
required.
I propose we change n_revbin to mpir_revbin.
All of the fft_blah and ifft_blah functions should become
mpir_fft_blah and mpir_ifft_blah. This will also prevent future
potential clashes with GMP.
And I think all the mpn_blah functions (although ostensibly well-named
for the time being) should become mpir_blah. The other option is for
flint to rename the mpn functions to something else. But what to
rename them? They are in our mpn_extras module. They won't be exported
publicly in MPIR, so we certainly cannot simply do a #if defined
around them in flint. And anyway, even if we did export them publicly
in MPIR (which is an option worth considering), we'd have to call them
mpir_blah anyway, to prevent potential future conflict with GMP.
Another issue is that (rightly or wrongly) all these mpn_extra
functions have been in a published flint interface for some time. So
it makes at least some sense to change the names in MPIR not flint. On
the other hand, mpn is a namespace belonging to gmp/mpir, so how to
handle mpn_extras functions in flint remains an unsolved problem.
In the mean time, if there are no immediate objections, I will make
all the functions after the break in the above list static in mpir,
and I will change all the (i)fft_blah functions to mpir_(i)fft_blah in
mpir. I remain open to suggestions regarding the mpn_blah functions.
======================
If you rename any global functions with very long names, please be careful
about any increases in symbol length as these have caused previous problems
on Windows.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
