On Wed, Oct 17, 2012 at 6:10 PM, Bill Hart <goodwillh...@googlemail.com> wrote: > 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.
We should probably rename the mpn_* functions in flint to flint_mpn_* or something similar. I doubt these functions are currently used externally anyway. There are even some inline functions in flint.h that override mpir functions (such as mpn_copyi), and this could potentially cause trouble. Fredrik -- 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.
