It's surely as much an issue for them as it is for us. I personally would be inclined to discuss the issue with them as they seem like reasonable and helpful people.
Of course they aren't going to fix it overnight, whereas we want to release as soon as possible. So this is indeed going to be an annoying issue for a while. We may have to not support large sizes until at least MPFR agree to the changes. Is it possible to add a single #define to MPIR that allows the build to be switched from one to the other easily? That way at least users can decide. Bill. 2010/1/8 Cactus <rieman...@googlemail.com>: > > > On Jan 8, 5:19 pm, Cactus <rieman...@googlemail.com> wrote: >> The change to mp_size_t and mp_exp_t on WIndows to use a 64-bit long >> long type seems to be incompatible with MPFR. >> >> After accounting for the addition of a __GMP_MP_SIZE_T_INT value of 2, >> the following MPFR assertion fails: >> >> ..\..\init2.c:42: MPFR assertion failed: >> ((mp_exp_t)((~((~(unsigned int)0)>>1))+2)) == (((-2147483647L - >> 1))+2) >> >> This is the the following macro: >> >> /* Check for correct EXP NAN, ZERO & INF in both mpfr.h and in mpfr- >> impl.h */ >> MPFR_ASSERTN( __MPFR_EXP_NAN == MPFR_EXP_NAN ); >> >> which can be tracked to: >> >> #if __GMP_MP_SIZE_T_INT >> #define __MPFR_EXP_NAN ((mp_exp_t)((~((~(unsigned int)0)>>1))+2)) >> #else >> #define __MPFR_EXP_NAN ((mp_exp_t)((~((~(unsigned long)0)>>1))+2)) >> #endif >> >> and: >> >> # define MPFR_EXP_NAN (MPFR_EXP_MIN+2) >> >> I haven't much of a clue what is going on but we don't want a release >> that doesn't support MPFR. > > Unfortunately MPFR depends on mp_size_t, mp_exp_t and > __GMP_MP_SIZE_T_INT in quite a few palces so MPFR is not going to work > with MPIR unless we either revert to a 32-bit type for these types or > the MPFR team makes changes to accomodate our changes to MPIR in thsi > regard. > > So we have to decide what to do: > > 1) revert to 32-bit types and give up huge integer values > 2) request changes to MPFR to accomadate our needed MPIR changes. > > ANy view on whiich way to go? > > 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-de...@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-de...@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.
