Release candidate 3

[Bill Hart]

I've made some changes to some documentation due to some incorrect bug
addresses pointed out by Paul Zimmermann.

I've also done some hacking to the autotools stuff to stop these silly
errors I was getting on sage.math.

The new tarball replaces the old at:

http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz

If this passes Michael's testing with Sage and build testing on SkyNet
it will become 0.9.0 final and be released.

Known issues:

- MSYS and mingw32 --enable-fat build issue has not been resolved
(will be fixed in service release)
- cygwin32 does not support make check after build in a directory
whose full path contains spaces
- no 32 bit x86 support for Apple gcc (see http://trac.mpir.org/mpir_trac/ticket/94
for workaround)
- make tune will core dump with small probability on some old Sun
blade machines with Sun cc compiler
- possible memory leak in t-locale (test code only and no one has
replicated it since it was reported)
- Generic build (without assembly, i.e. with -host=none) will fail on
x86_64 (will be fixed in service release)

Bill.

[mabshoff]

On Feb 4, 10:30 am, Bill Hart <goodwillh...@googlemail.com> wrote:
> I've made some changes to some documentation due to some incorrect bug
> addresses pointed out by Paul Zimmermann.
>
> I've also done some hacking to the autotools stuff to stop these silly
> errors I was getting on sage.math.
>
> The new tarball replaces the old at:
>
> http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz
>
> If this passes Michael's testing with Sage and build testing on SkyNet
> it will become 0.9.0 final and be released.

Ok, I tested on

SkyNet?:

* eno (x86_64, FC9)
* mark (Sparc, Solaris)
* fulvia (x86, Solaris)
* cicero (x86, FC9)
* menas (x86_64, OpenSUSE 10.3)
* iras (Itanium, SLES 10)
* cleo (Itanium, RHEL 5.2)
* varro (PPC, OSX 10.4)

Misc machines:

* bsd (x86, OSX 10.5)
* sage.math (x86_64, Ubuntu LTS 8.04)
* sprocketer (x86-64, OSX 10.5)

and mpir's make check as well as mpfr's make check build against that
mpir release passed. I will do a full build of Sage against that mpir
tonight [alpha6 got delayed by some bugs, but that isn't anything
new :)]

> Known issues:
>
> - MSYS and mingw32 --enable-fat build issue has not been resolved
> (will be fixed in service release)
> - cygwin32 does not support make check after build in a directory
> whose full path contains spaces

> - no 32 bit x86 support for Apple gcc (seehttp://trac.mpir.org/mpir_trac/ticket/94

> for workaround)
> - make tune will core dump with small probability on some old Sun
> blade machines with Sun cc compiler
> - possible memory leak in t-locale (test code only and no one has
> replicated it since it was reported)
> - Generic build (without assembly, i.e. with -host=none) will fail on
> x86_64 (will be fixed in service release)

- configure && make outside of the main directory fails [reported by
Mariah]

> Bill.

Cheers,

Michael

[mabshoff]

Ok, testing turned up this:

Build failed on Mac OS X, Intel iMac while compiling gmp-mpir:

PASS: t-assign
PASS: t-binary
PASS: t-cast
PASS: t-constr
PASS: t-headers
PASS: t-istream
istream mpf_t operator>> wrong
point ,
str "1,"
got 123
want 1
localeconv point ","
/bin/sh: line 1: 13352 Abort trap ${dir}$tst
FAIL: t-locale
PASS: t-misc
PASS: t-ops
PASS: t-ostream
PASS: t-prec
PASS: t-rand
PASS: t-ternary
PASS: t-unary
=============================================================
1 of 14 tests failed
Please report to http://groups.google.co.uk/group/mpir-devel/
=============================================================
make[6]: *** [check-TESTS] Error 1
make[5]: *** [check-am] Error 2
make[4]: *** [check-recursive] Error 1
make[3]: *** [check-recursive] Error 1
make[2]: *** [check] Error 2

real 3m26.276s
user 2m16.034s
sys 2m7.349s
sage: An error occurred while installing gmp-mpir-0.9.rc3

I am asking for the build log and other info and the person is
certainly capable of testing fixes.

Cheers,

Michael

[William Stein]

On Sun, Feb 8, 2009 at 10:36 AM, mabshoff
<Michael...@mathematik.uni-dortmund.de> wrote:
>
> Ok, testing turned up this:
>
> Build failed on Mac OS X, Intel iMac while compiling gmp-mpir:

The exact same failure happens on OS X 10.5 PPC iMac, and on OS X10.5
Intel MacPro and MacbookPro's.

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[mabshoff]

On Feb 8, 11:41 am, William Stein <wst...@gmail.com> wrote:
> On Sun, Feb 8, 2009 at 10:36 AM, mabshoff
>

> <Michael.Absh...@mathematik.uni-dortmund.de> wrote:
>
> > Ok, testing turned up this:
>
> > Build failed on Mac OS X, Intel iMac while compiling gmp-mpir:
>
> The exact same failure happens on OS X 10.5 PPC iMac, and on OS X10.5
> Intel MacPro and MacbookPro's.

Posting the same thing as on sage-devel:

Mhh, this is strange since I did test the gmp-mpir.spkg on bsd, but I
had one version that skipped the test suite for mpir accidentally, so
I might have run the old one on my laptop and also bsd. I did rerun
the corrected spkg on varro, so it does pass doctests on PPC OSX 10.4.
I just saw that you reported the problem on OSX 10.5 PPC, too, so this
might be XCode dependent to some extend.

I also just reran the test suite on my laptop in 64 bit mode and am
hitting the same problem. Since this is a C++ issue my guess would be
that this might be related to the Sun Forte C++ fix that Bill did.

Either way, scratch one up for mandated spkg-check :)

Cheers,

Michael

[mabshoff]

Ok, I just check again to be 100% sure an on varro, i.e. OSX 10.4/PPC
using

varro:~/sage-3.3.alpha6-32 mabshoff$ gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-
checking -enable-werror --prefix=/usr --mandir=/share/man --enable-
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/
lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --
target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)


The build of Sage 3.3.a6 including "make check" for mpir-0.9.rc3
passed and the only failed doctests for "-long" was a known failure
involving gp where OSX couldn't allocate enough memory.

Since Bill has access to bsd he should be able to reproduce the
problem. I can also bisect before and after the Sun Forte C++ fix to
see if that one is the culprit.

Cheers,

Michael

[Bill Hart]

I don't understand what the t-locale test actually does. It looks to
me like in some parts of the world a decimal point is a comma and this
test somehow changes to that locale and tries to set an mpf to the
value given in a string (containing a comma).

It works just fine when the string uses a decimal point for a decimal
point. But not when it uses a comma.

I don't have access to bsd, so if someone could test revisions 1540
and 1545 to see if it used to pass the test on these machines for
either of those revisions, I would be grateful. I don't really see how
anything I touched would affect the locale stuff. Some of the fixes
were Sun CC only, not Apple. Other fixes were simply #including
cstdlib or something of that nature.

But then again I don't know much about C++ at all, and least of all
about locales.

Bill.

2009/2/8 mabshoff <Michael...@mathematik.uni-dortmund.de>:

[mabshoff]

On Feb 8, 2:19 pm, Bill Hart <goodwillh...@googlemail.com> wrote:

Hi Bill,

> I don't understand what the t-locale test actually does. It looks to
> me like in some parts of the world a decimal point is a comma and this
> test somehow changes to that locale and tries to set an mpf to the
> value given in a string (containing a comma).
>
> It works just fine when the string uses a decimal point for a decimal
> point. But not when it uses a comma.
>
> I don't have access to bsd,

Yes, you do since I reminded you how to get there :)

> so if someone could test revisions 1540
> and 1545 to see if it used to pass the test on these machines for
> either of those revisions, I would be grateful. I don't really see how
> anything I touched would affect the locale stuff. Some of the fixes
> were Sun CC only, not Apple. Other fixes were simply #including
> cstdlib or something of that nature.
>
> But then again I don't know much about C++ at all, and least of all
> about locales.
>
> Bill.

After some more discussion it seems to be that only

GCC Version

gcc -v
Using built-in specs.

Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-

checking -enable-werror --prefix=/usr --mandir=/share/man --enable-
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/

lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --
host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)

shows this problem. All three cases where we had failures (John
Palmieri's original repo, bsd and also my laptop) run the above
revision of gcc, i.e. down to the build number.

Cheers,

Michael

[Bill Hart]

This issue is caused by gmp-impl.h defining GMP_DECIMAL_POINT
differently depending on which file gmp-impl.h is defined from. Yes,
this is possible!!

Gonzalo Tornaria figured it out.

Bill.

2009/2/8 mabshoff <Michael...@mathematik.uni-dortmund.de>:

[Bill Hart]

This is bizarre. Revision 1591 passes on bsd. But the head (revision
1599) does not.

The only changes made between these two were:

1) Updating the authors file, changing some bug reporting addresses in
some text, etc.

2) Removing some ANSI2KNR stuff from the autotools files as this is
not supported by the latest autotools.

3) Running aclocal, automake and autoconf again.

None of this should affect it, but it does.

At any rate, we can revert it and just put the changes to the text
files back in. The *only* reason I changed the ANSI2KNR stuff was that
one needs to rerun automake after changing the bug reporting address
in the Makefile.am so that make install doesn't tell you to report
bugs to Torbjorn. Basically I cannot run automake on sage.math because
the latest autotools is on there and MPIR breaks it (due to this
ANSI2KNR stuff).

So I guess the good news is that if we get someone else to run
autoconf and automake, we should be ok. I can't even guess at what
brilliant feature of the new autotools breaks the test code on certain
versions of Apple's compiler.

Bill.

2009/2/9 Bill Hart <goodwi...@googlemail.com>:

[ja...@njkfrudils.plus.com]

On Monday 09 February 2009 16:25:23 Bill Hart wrote:
> This is bizarre. Revision 1591 passes on bsd. But the head (revision
> 1599) does not.
>
> The only changes made between these two were:
>
> 1) Updating the authors file, changing some bug reporting addresses in
> some text, etc.
>
> 2) Removing some ANSI2KNR stuff from the autotools files as this is
> not supported by the latest autotools.
>
> 3) Running aclocal, automake and autoconf again.
>
> None of this should affect it, but it does.
>
> At any rate, we can revert it and just put the changes to the text
> files back in. The *only* reason I changed the ANSI2KNR stuff was that
> one needs to rerun automake after changing the bug reporting address
> in the Makefile.am so that make install doesn't tell you to report
> bugs to Torbjorn. Basically I cannot run automake on sage.math because
> the latest autotools is on there and MPIR breaks it (due to this
> ANSI2KNR stuff).
>
> So I guess the good news is that if we get someone else to run
> autoconf and automake, we should be ok. I can't even guess at what
> brilliant feature of the new autotools breaks the test code on certain
> versions of Apple's compiler.
>
> Bill.
>

I just ran autostuff on rev1599 and a lot of changes appeared , it looks like
its not been run , anyway
I can do it , exactly which version r???? and do I do a revert or what?

Jason

[Bill Hart]

If we can:

1) revert ****trunk**** to revision 1593
2) copy trunk/AUTHORS to trunk/build.vc9/gnu.license/AUTHORS
3) copy trunk/README to trunk/build.vc9/gnu.license/README
4) run autoconf
5) run automake
6) commit

I think everything should work. If you can do this it would be great.

Bill.

2009/2/9 <ja...@njkfrudils.plus.com>:

[ja...@njkfrudils.plus.com]

On Monday 09 February 2009 21:47:44 Bill Hart wrote:
> If we can:
>
> 1) revert ****trunk**** to revision 1593
> 2) copy trunk/AUTHORS to trunk/build.vc9/gnu.license/AUTHORS
> 3) copy trunk/README to trunk/build.vc9/gnu.license/README
> 4) run autoconf
> 5) run automake
> 6) commit
>
> I think everything should work. If you can do this it would be great.
>
> Bill.

mkdir mpirtest
cd mpirtest
svn checkout -r 1593 http://modular.math.jmu.edu/svn/mpir
cd mpir/mpir/trunk
cp AUTHORS build.vc9/gnu.license/AUTHORS
cp README build.vc9/gnu.license/README
autoconf
automake
svn commit -m "revert to r1593 and try autostuff again"

Sending trunk/Makefile.in
svn: Commit failed (details follow):
svn: Your file or directory 'Makefile.in' is probably out-of-date
svn: The version resource does not correspond to the resource within the
transaction. Either the requested version resource is out of date (needs to
be updated), or the requested version resource is newer than the transaction
root (restart the commit).

I think I need to revert mpir rather than do the above , any ideas?

[Gonzalo Tornaria]

In order to revert trunk to revision 1593, you actually need to do a
"reverse merge" of all the changes between r1593 and HEAD.

See: http://svnbook.red-bean.com/en/1.2/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.undo

I guess something like:

svn merge -r HEAD:1593 .

should work... (you may need to replace "." by the full URL of trunk
if you are not using svn 1.5).

I would suggest doing a separate commit just for the revert, and put
the autostuff update in a different commit, but that's just a matter
of taste...

Gonzalo

[Bill Hart]

Yeah svn won't allow you to revert, modify then recommit.

Probably the best thing is to make a reverse diff between the two
revisions and apply it to head, then commit.

Bill.

[Bill Hart]

Actually this is better. Reverse diff which I suggested won't work.

Bill.

2009/2/9 Gonzalo Tornaria <torn...@gmail.com>:

[ja...@njkfrudils.plus.com]

Thunderbirds are GO...


root@box1:~/mpir/mpir/mpir/trunk# svn status
root@box1:~/mpir/mpir/mpir/trunk# svn update
At revision 1599.
root@box1:~/mpir/mpir/mpir/trunk# svn merge -r 1599:1593 .
U mpf/Makefile.in
U Makefile.in
U mpn/Makefile.in
U mpq/Makefile.in
U build.vc9/gnu.license/AUTHORS
U build.vc9/gnu.license/README
U cxx/Makefile.in
U doc/Makefile.in
U mpz/Makefile.in
U demos/Makefile.in
U demos/calc/Makefile.in
U demos/expr/Makefile.in
U configure.in
U scanf/Makefile.in
U tune/Makefile.in
U configure
U tests/Makefile.in
U tests/mpf/Makefile.in
U tests/mpn/Makefile.in
U tests/mpq/Makefile.in
U tests/devel/Makefile.in
U tests/cxx/Makefile.in
U tests/mpz/Makefile.in
U tests/rand/Makefile.in
U tests/misc/Makefile.in
U tests/mpbsd/Makefile.in
U printf/Makefile.in
U mpbsd/Makefile.in
U Makefile.am
U aclocal.m4
root@box1:~/mpir/mpir/mpir/trunk# svn status
M Makefile.in
M mpf/Makefile.in
M mpn/Makefile.in
M mpq/Makefile.in
M build.vc9/gnu.license/AUTHORS
M build.vc9/gnu.license/README
M cxx/Makefile.in
M doc/Makefile.in
M mpz/Makefile.in
M demos/calc/Makefile.in
M demos/Makefile.in
M demos/expr/Makefile.in
M configure.in
M scanf/Makefile.in
M tune/Makefile.in
M configure
M tests/mpf/Makefile.in
M tests/Makefile.in
M tests/mpn/Makefile.in
M tests/mpq/Makefile.in
M tests/devel/Makefile.in
M tests/cxx/Makefile.in
M tests/mpz/Makefile.in
M tests/rand/Makefile.in
M tests/misc/Makefile.in
M tests/mpbsd/Makefile.in
M printf/Makefile.in
M mpbsd/Makefile.in
M Makefile.am
M aclocal.m4
root@box1:~/mpir/mpir/mpir/trunk# svn commit -m "reverted to rev 1593"
Sending trunk/Makefile.am
Sending trunk/Makefile.in
Sending trunk/aclocal.m4
Sending trunk/build.vc9/gnu.license/AUTHORS
Sending trunk/build.vc9/gnu.license/README
Sending trunk/configure
Sending trunk/configure.in
Sending trunk/cxx/Makefile.in
Sending trunk/demos/Makefile.in
Sending trunk/demos/calc/Makefile.in
Sending trunk/demos/expr/Makefile.in
Sending trunk/doc/Makefile.in
Sending trunk/mpbsd/Makefile.in
Sending trunk/mpf/Makefile.in
Sending trunk/mpn/Makefile.in
Sending trunk/mpq/Makefile.in
Sending trunk/mpz/Makefile.in
Sending trunk/printf/Makefile.in
Sending trunk/scanf/Makefile.in
Sending trunk/tests/Makefile.in
Sending trunk/tests/cxx/Makefile.in
Sending trunk/tests/devel/Makefile.in
Sending trunk/tests/misc/Makefile.in
Sending trunk/tests/mpbsd/Makefile.in
Sending trunk/tests/mpf/Makefile.in
Sending trunk/tests/mpn/Makefile.in
Sending trunk/tests/mpq/Makefile.in
Sending trunk/tests/mpz/Makefile.in
Sending trunk/tests/rand/Makefile.in
Sending trunk/tune/Makefile.in
Transmitting file data ..............................
Committed revision 1600.
root@box1:~/mpir/mpir/mpir/trunk#
root@box1:~/mpir/mpir/mpir/trunk# cp AUTHORS build.vc9/gnu.license/AUTHORS
root@box1:~/mpir/mpir/mpir/trunk# cp README build.vc9/gnu.license/README
root@box1:~/mpir/mpir/mpir/trunk# autoconf
root@box1:~/mpir/mpir/mpir/trunk# automake
root@box1:~/mpir/mpir/mpir/trunk# svn commit -m "cp AUTHORS,README to
build.vc9/gnu.license/ and run autoconf,automake"
Sending trunk/Makefile.in
Sending trunk/build.vc9/gnu.license/AUTHORS
Sending trunk/build.vc9/gnu.license/README
Transmitting file data ...
Committed revision 1601.

[ja...@njkfrudils.plus.com]

On Tuesday 10 February 2009 00:29:00 ja...@njkfrudils.plus.com wrote:

maybe we need to run autoheader as well?

running on my local , it changes config.in to below

root@box1:~/mpir/mpir/mpir/trunk# svn status
? autom4te.cache
M config.in
root@box1:~/mpir/mpir/mpir/trunk# diff config.in config.in~
133c133,134
< If your CPU is not in any of these families, leave all undefined. */
---
> If your CPU is not in any of these families, leave all undefined.
> For an AMD64 chip, define "x86" in ABI=32, but not in ABI=64. */
139d139
< #undef HAVE_HOST_CPU_FAMILY_x86_64
root@box1:~/mpir/mpir/mpir/trunk#

[Bill Hart]

Thanks jason, this passes on bsd. So.....

Release candidate 4:

sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz

Known issues:

- MSYS and mingw32 --enable-fat build issue has not been resolved
(will be fixed in service release)
- cygwin32 does not support make check after build in a directory
whose full path contains spaces
- no 32 bit x86 support for Apple gcc (see
http://trac.mpir.org/mpir_trac/ticket/94
for workaround)
- make tune will core dump with small probability on some old Sun
blade machines with Sun cc compiler
- possible memory leak in t-locale (test code only and no one has
replicated it since it was reported)
- Generic build (without assembly, i.e. with -host=none) will fail on
x86_64 (will be fixed in service release)

- configure and make outside the source directory fails

Bill.


2009/2/10 <ja...@njkfrudils.plus.com>: