On 17 October 2012 19:04, Fredrik Johansson <fredrik.johans...@gmail.com> wrote: > 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.
Yes, I think we should do this, despite it changing the interface (and creating a modicum of extra work for us). > > 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. > I think it should only do this if the functions are not defined in mpir.h. So this should be safe. We should check that this is indeed the case though. 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.
