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 -~----------~----~----~----~------~----~------~--~---
