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. Bill. -- 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.