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 <goodwillh...@googlemail.com>: > 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.absh...@mathematik.uni-dortmund.de>: >> >> >> >> 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 >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
