It's so long since I looked at this, I don't remember. But I had thought it was because these functions were not universally exported in mpir.
If they are macros in flint, then I don't see the problem anyway. They don't get exported as symbols in the flint library. They will be picked up by any project that uses mpir.h and flint.h, but the functionality is surely identical and unlikely to change. If it does, this will be a problem for more than just flint users. Bill. On 17 October 2012 19:48, Fredrik Johansson <fredrik.johans...@gmail.com> wrote: > On Wed, Oct 17, 2012 at 8:31 PM, Bill Hart <goodwillh...@googlemail.com> > wrote: >> 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. > > The mpir functions are being unconditionally undef'ed. I was under the > impression that this was done to get versions without the function > call overhead for small input. The flint versions shouldn't break any > code, but they might not be what the user wants. > > 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. > -- 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.
