GPL and not LGPL? I suppose that is not a problem, so long as it is not built as part of the library...
Bill. 2010/1/5 Cactus <rieman...@googlemail.com>: > > > On Jan 5, 8:10 am, Cactus <rieman...@googlemail.com> wrote: >> On Jan 4, 8:02 pm, Cactus <rieman...@googlemail.com> wrote: >> >> >> >> > On Jan 4, 6:56 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >> >> > > It looks like we have the following in mpir.h: >> >> > > #if defined (_CRAY) && ! defined (_CRAYMPP) >> > > /* plain `int' is much faster (48 bits) */ >> > > #define __GMP_MP_SIZE_T_INT 1 >> > > typedef int mp_size_t; >> > > typedef int mp_exp_t; >> > > #else >> > > #define __GMP_MP_SIZE_T_INT 0 >> > > typedef long int mp_size_t; >> > > typedef long int mp_exp_t; >> > > #endif >> >> > > So on most linux machines we'll have mp_size_t is a long. That is >> > > indeed the problem for Windows. I think it is safer to guard it to >> > > prevent any possibility of issues. I'm unsure what happens on Sparc. >> >> > I will also have to add other options to __GMP_MP_SIZE_T_INT to set >> > the right follow on definitions in gmp-impl.h: >> >> > #if __GMP_MP_SIZE_T_INT >> > #define MP_SIZE_T_MAX INT_MAX >> > #define MP_SIZE_T_MIN INT_MIN >> > #else >> > #define MP_SIZE_T_MAX LONG_MAX >> > #define MP_SIZE_T_MIN LONG_MIN >> > #endif >> >> I have now tried this and, unfortunately, one test (mpz io_raw) fails >> when MPIR calls realloc with a current memory block of 8 bytes and a >> new block request of 1 byte. >> >> It _ssems_ (I am not yet sure about this) that Windows doesn't bother >> to reallocate in this situation and MPIR sees this as an error. > > In looking at this isssue, I have discovered that realloc on Windows > is a frequent source of performance problems on WIndows. This leads > me to wonder whether it might be worth trying another memory > manager .. > > Does anyone have experience with Hoard - it seems to have a pretty > good reputation and is GPL v2 licensed. > > 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.
