I've added what I think we should try, to: http://trac.mpir.org/mpir_trac/ticket/112
Bill. 2009/2/5 Bill Hart <goodwillh...@googlemail.com>: > Well I wonder if one fixed the declaration to export the correct mpbsd > function name and prototype whether it would just work. > > I also wonder if *we* did this or if it was already broken in GMP > 4.2.1. To me it looks like it got messed up when the new gcd patches > were added. > > Probably we should not export mpz_rgcd, mpz_ngcd, etc, when > BERKELEY_MP is defined. We should only export the berkeley equivalent > of mpz_gcd. > > Here is what happens in mpz mul.c for mpz_mul: > > #ifdef BERKELEY_MP > #include "mp.h" > #endif > > > void > #ifndef BERKELEY_MP > mpz_mul (mpz_ptr w, mpz_srcptr u, mpz_srcptr v) > #else /* BERKELEY_MP */ > mult (mpz_srcptr u, mpz_srcptr v, mpz_ptr w) > #endif /* BERKELEY_MP */ > > So, it looks to me from that one includes mp.h in addition to gmp.h > and gmp-impl.h when building for mpbsd. > > In mp.h we have: > > __GMP_DECLSPEC void gcd __GMP_PROTO ((const MINT *, const MINT *, MINT *)); > > So that's probably the declaration we need. In particular it looks > like the output goes last. > > MINT is defined to be: > > typedef __mpz_struct MINT; > > so probably just reordering the parameters in the function declaration > will do (if BERKELEY_MP is defined of course). > > I don't recall what the __GMP_DECLSPEC does, but probably just leave > it out. Well if we look at the mpz_mul declaration as an example then > that seems right. > > In other words we could try > > #include mp.h > > and > > void gmp(mpz_srcptr u, mpz_srcptr v, mpz_ptr g); > > when BERKELEY_MP is defined. If it doesn't work, well I guess we raise > a petition to remove mpbsd (after we figure out what it was there for > in the first place). > > At any rate, this seems unimportant for MPIR 0.9.0. We'll do all this > for MPIR 1.0.0. I'll open a ticket for the mpbsd issue. > > Bill. > > 2009/2/5 <ja...@njkfrudils.plus.com>: >> >> On Thursday 05 February 2009 20:18:29 Bill Hart wrote: >>> 2009/2/5 <ja...@njkfrudils.plus.com>: >>> > On Wednesday 04 February 2009 19:54:03 Bill Hart wrote: >>> >> Thanks. As soon as we release, it would be great if you could give it >>> >> a go and we can issue a service release. >>> > >>> > Should I create a branch for it? >>> >>> I don't think that is a good idea. We should release, then do this in >>> trunk. Otherwise we are going to have to do it all over again! >>> >>> I would release, but I am still waiting on: >>> >>> 1) Results of mabshoff's build testing on SkyNet >>> >>> 2) Someone to move the tarball and webpage over to www.mpir.org (I >>> don't have access). >>> >>> > I cant do the windows bits , Brian ? >>> >>> Brian already did this once, so I am sure he will be able to do it >>> again once we make the decision to switch to libmpir instead of >>> libgmp. >>> >>> > I dont do C++ , and I dont know how comprehensive the make check c++ bit >>> > is , if someone can email me some c++ programs , I can test them >>> >>> Oh yes, we also have libgmpxx. I had forgotten about that. I also don't do >>> c++. >>> >>> > I can leave or delete the old directory mpbsd ? >>> >>> Don't think we can delete that. I don't know who uses it, but we >>> shouldn't get rid of it unless we are absolutely sure. >>> >> >> Doesn't build anyway >> >> ../mp.h:151: warning: conflicting types for built-in function 'pow' >> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DBERKELEY_MP -D__GMP_WITHIN_GMP >> -D__gmpz_realloc=_mp_realloc -I.. -I../mpz -O2 -m64 -march=k8 -mtune=k8 -c >> ../mpz/cmp.c -o >> cmp.o >/dev/null 2>&1 >> /bin/sh ../libtool --tag=CC --mode=compile >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DBERKELEY_MP -D__GMP_WITHIN_GMP >> -D__gmpz_realloc=_mp_realloc -I.. -I../mpz -O2 -m64 -march=k8 -mtune=k8 >> -c -o >> gcd.lo `test -f '../mpz/gcd.c' || echo './'`../mpz/gcd.c >> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DBERKELEY_MP -D__GMP_WITHIN_GMP >> -D__gmpz_realloc=_mp_realloc -I.. -I../mpz -O2 -m64 -march=k8 -mtune=k8 -c >> ../mpz/gcd.c -fPIC -DPIC -o .libs/gcd.o >> ../mpz/gcd.c:27:3: error: #error BERKELEY_MP not supported >> make[2]: *** [gcd.lo] Error 1 >> make[2]: Leaving directory `/root/mpir/mpir/mpir/trunk/mpbsd' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/root/mpir/mpir/mpir/trunk' >> make: *** [all] Error 2 >> >> >> >>> > I assume we are going to leave internal names as __gmp_blah etc >>> >>> Yes, no function names should change. >>> >>> Bill. >>> >>> >> Bill. >>> >> >>> >> 2009/2/4 <ja...@njkfrudils.plus.com>: >>> >> > On Wednesday 04 February 2009 18:35:24 Bill Hart wrote: >>> >> >> Hi Mariah, >>> >> >> >>> >> >> 2009/2/4 Mariah <mariah.le...@gmail.com>: >>> >> >> > Bill, >>> >> >> > >>> >> >> > On Feb 4, 12:25 am, Bill Hart <goodwillh...@googlemail.com> wrote: >>> >> >> >> I have placed a tarball here: >>> >> >> >> >>> >> >> >> http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz >>> >> >> > >>> >> >> > Some quick observations - >>> >> >> > >>> >> >> > 1. It looks like you have to build in the source tree. Many >>> >> >> > software packages let you have an object directory separate from >>> >> >> > the source directory. This is useful for networks with lots of >>> >> >> > different architectures hanging on them. You only need one copy of >>> >> >> > the source file. >>> >> >> >>> >> >> Autotools is supposed to let you do that as standard. We may have >>> >> >> broken something which allows that, or perhaps it was never possible >>> >> >> with GMP. I don't know. I'll add a trac ticket and we can look at >>> >> >> this. >>> >> >> >>> >> >> > 2. The built include and library files are gmp.h, libgmp.a, etc. >>> >> >> > Shouldn't they be mpir.h, libmpir.a? Leaving the names as gmp.h, >>> >> >> > libgmp.a may discourage system dministrators from overwriting the >>> >> >> > system gmp.h, libgmp.a from GNU gmp. I can see that you may need an >>> >> >> > option for symbolic links (gmp.h -> mpir.h, etc) for legacy >>> >> >> > software that expects (gmp.h, libgmp.a). But surely you want to >>> >> >> > encourage projects to transition to MPIR (and not remain with GMP). >>> >> >> >>> >> >> We have decided not to do this for MPIR-0.9.0. >>> >> >> >>> >> >> Actually, none of us know how to do it aanyway! Perhaps either you or >>> >> >> Michael can help with this. I looked into it and didn't even know >>> >> >> where to start. We do have a trac ticket for it. >>> >> >> >>> >> >> Bill. >>> >> > >>> >> > I know how to do this , mostly. >>> >> > >>> >> > Jason >>> >>> >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
