It may be something intrinsic to the architecture that makes timings unstable on this kind of machine. Every time I ran FFT-tuning for example, results were quite different.
Bill. 2009/6/2 Jason Moxham <[email protected]>: > > The netburst machine I use is root/single user , so timings should be good , > didn't have a problem before . The only problem I have is I have to submit it > as a batch file (that works first time!!!) , like the old mainframe days. > > On Tuesday 02 June 2009 16:45:33 Bill Hart wrote: >> I've committed make tune values for netburst, but decided against >> doing FFT-tuning and FFT-tuning2 as the timings are too erratic to be >> meaningful. >> >> Bill. >> >> 2009/6/2 Bill Hart <[email protected]>: >> > In common.c I changed t and t_unsorted to be arrays of length 100 >> > instead of 30. This appears to allow me to get tuning values for this >> > machine. >> > >> > Bill. >> > >> > 2009/6/2 Bill Hart <[email protected]>: >> >> There's no point doing FFT tuning on this machine. Times vary by more >> >> than a factor of 2. I'll just produce ordinary make tune values. >> >> >> >> Bill. >> >> >> >> 2009/6/2 Bill Hart <[email protected]>: >> >>> It passes make check, but timings are so erratic I'm unable to get >> >>> ordinary make tune values. I've set the precision to 20000000 and it >> >>> still occasionally drops out and it takes forever. >> >>> >> >>> Bill. >> >>> >> >>> 2009/6/2 Jason Moxham <[email protected]>: >> >>>> I may be able to do netburst as I have occasional access, , I'll see >> >>>> if I can get acces. I see if I can figure out the timing on >> >>>> cato(mips64) as well. >> >>>> >> >>>> On Tuesday 02 June 2009 13:29:33 Bill Hart wrote: >> >>>>> That only leaves netburst, netburstlahf, atom, mips64 and windows >> >>>>> tuning values to get, which I will do asap. So far Brian and I still >> >>>>> have no idea why the timing code on Windows is so erratic. Tuning is >> >>>>> currently impossible there. We may have to ship without it if we >> >>>>> cannot resolve the issues in the next day or two. Unfortunately I >> >>>>> only have 32 bit Windows and VS Express, so I am currently of little >> >>>>> help. >> >>>>> >> >>>>> Bill. >> >>>>> >> >>>>> 2009/6/2 Jason Moxham <[email protected]>: >> >>>>> > Mark2 passes all tests now , and we have done the fft tuning on >> >>>>> > mark and varro >> >>>>> > >> >>>>> > I can't reproduce the weird libgcc error on mark , I suspose I was >> >>>>> > typing something wrong :( >> >>>>> > >> >>>>> > On Monday 01 June 2009 18:08:26 Jason Moxham wrote: >> >>>>> >> I retested fulvia again for all the usual builds/gcc/cc etc and it >> >>>>> >> passed. I still waiting for mark2 to finish the same , and still >> >>>>> >> waiting for mark to finish the FFT tuning >> >>>>> >> >> >>>>> >> I going to try FFT tuning on varro again, 2nd time lucky!! >> >>>>> >> >> >>>>> >> Jason >> >>>>> >> >> >>>>> >> On Monday 01 June 2009 15:31:52 Jason Moxham wrote: >> >>>>> >> > I reran autotools and that fixes the problem :) >> >>>>> >> > >> >>>>> >> > The problem may not be with autotools but the gmp configure >> >>>>> >> > script , which I *guess* is put together by people who hate it , >> >>>>> >> > ie us :) >> >>>>> >> > >> >>>>> >> > Better use slackware , so old , it will run stonehenge >> >>>>> >> > >> >>>>> >> > http://www.earthview.com/ages/stonehenge.htm >> >>>>> >> > >> >>>>> >> > On Monday 01 June 2009 15:19:01 Bill Hart wrote: >> >>>>> >> > > The ones shipped with Ubuntu and SUSE both seem broken (in >> >>>>> >> > > different ways). >> >>>>> >> > > >> >>>>> >> > > Bill. >> >>>>> >> > > >> >>>>> >> > > 2009/6/1 Jason Moxham <[email protected]>: >> >>>>> >> > > > On Monday 01 June 2009 15:13:29 Bill Hart wrote: >> >>>>> >> > > >> Revision 2070 builds with --enable-cxx and passes. >> >>>>> >> > > >> >> >>>>> >> > > >> Probably if you check out revision 2071, run aclocal, >> >>>>> >> > > >> autoheader, autoconf, automake, etc it will all be ok >> >>>>> >> > > >> again. >> >>>>> >> > > >> >> >>>>> >> > > >> You'll have to add back in your sparc64 tuning and in >> >>>>> >> > > >> Makefile.am change mpirbench.sln to build.vc9 as this file >> >>>>> >> > > >> has now moved inside the directory. >> >>>>> >> > > >> >> >>>>> >> > > >> I thought I had finally found an autotools which didn't >> >>>>> >> > > >> cause a problem, but apparently not. >> >>>>> >> > > > >> >>>>> >> > > > I use autotools from slackware(32bit) or bluewhite(64bit) >> >>>>> >> > > > v12.1 (not latest) >> >>>>> >> > > > >> >>>>> >> > > >> Bill. >> >>>>> >> > > >> >> >>>>> >> > > >> 2009/6/1 Bill Hart <[email protected]>: >> >>>>> >> > > >> > OK, I get the same issue now. But it was only when I >> >>>>> >> > > >> > built with --enable-cxx. It does seem that libtool >> >>>>> >> > > >> > doesn't recognise the object files as output by the C++ >> >>>>> >> > > >> > compiler or something. >> >>>>> >> > > >> > >> >>>>> >> > > >> > It could be because I updated autotools, but it could >> >>>>> >> > > >> > also be something has changed on the machine. >> >>>>> >> > > >> > >> >>>>> >> > > >> > I'll try reverting to an earlier revision and see if the >> >>>>> >> > > >> > problem goes away. >> >>>>> >> > > >> > >> >>>>> >> > > >> > Bill. >> >>>>> >> > > >> > >> >>>>> >> > > >> > 2009/6/1 Bill Hart <[email protected]>: >> >>>>> >> > > >> >> I did get this when attempting to run configure: >> >>>>> >> > > >> >> >> >>>>> >> > > >> >> -bash: ./configure: /bin/sh: bad interpreter: Stale NFS >> >>>>> >> > > >> >> file handle >> >>>>> >> > > >> >> >> >>>>> >> > > >> >> Looks like the NFS filesystem might be a bit flakey on >> >>>>> >> > > >> >> that machine. >> >>>>> >> > > >> >> >> >>>>> >> > > >> >> Bill. >> >>>>> >> > > >> >> >> >>>>> >> > > >> >> 2009/6/1 Bill Hart <[email protected]>: >> >>>>> >> > > >> >>> I had no problems on fulvia with gcc-4.4.0. But I'm >> >>>>> >> > > >> >>> using a version of mpir-1.2 from before when I did >> >>>>> >> > > >> >>> >> >>>>> >> > > >> >>> aclocal >> >>>>> >> > > >> >>> autoheader >> >>>>> >> > > >> >>> autoconf >> >>>>> >> > > >> >>> automake >> >>>>> >> > > >> >>> makeinfo >> >>>>> >> > > >> >>> configure >> >>>>> >> > > >> >>> >> >>>>> >> > > >> >>> I'll try again by checking out trunk and see if I get >> >>>>> >> > > >> >>> the error. If so, you might have to run your autotools, >> >>>>> >> > > >> >>> as I'll have again found another broken autotools >> >>>>> >> > > >> >>> installation. >> >>>>> >> > > >> >>> >> >>>>> >> > > >> >>> Bill. >> >>>>> >> > > >> >>> >> >>>>> >> > > >> >>> 2009/6/1 Jason Moxham <[email protected]>: >> >>>>> >> > > >> >>>> we now have the same failure on mark , clearly >> >>>>> >> > > >> >>>> something has changed >> >>>>> >> > > >> >>>> >> >>>>> >> > > >> >>>> On Monday 01 June 2009 13:38:31 Bill Hart wrote: >> >>>>> >> > > >> >>>>> Great. Just keep committing to trunk. We're not at an >> >>>>> >> > > >> >>>>> rc yet, so no need to create the branch yet. >> >>>>> >> > > >> >>>>> >> >>>>> >> > > >> >>>>> I'm going to try and see if I have anything to offer >> >>>>> >> > > >> >>>>> the Windows timing code which seems to be playing up >> >>>>> >> > > >> >>>>> terribly and if not start testing on other build farm >> >>>>> >> > > >> >>>>> systems. >> >>>>> >> > > >> >>>>> >> >>>>> >> > > >> >>>>> Bill. >> >>>>> >> > > >> >>>>> >> >>>>> >> > > >> >>>>> 2009/6/1 Jason Moxham <[email protected]>: >> >>>>> >> > > >> >>>>> > On Monday 01 June 2009 13:19:53 Bill Hart wrote: >> >>>>> >> > > >> >>>>> >> Does it work if you do not use parallel make? >> >>>>> >> > > >> >>>>> > >> >>>>> >> > > >> >>>>> > no change, I have look in an hour or so , I'm also >> >>>>> >> > > >> >>>>> > retesting mark2 , make sure nothing has changed >> >>>>> >> > > >> >>>>> > there, The fft tuning on mark should be finished in >> >>>>> >> > > >> >>>>> > an hour or two. >> >>>>> >> > > >> >>>>> > >> >>>>> >> > > >> >>>>> > Jason >> >>>>> >> > > >> >>>>> > >> >>>>> >> > > >> >>>>> >> 2009/6/1 Jason Moxham <[email protected]>: >> >>>>> >> > > >> >>>>> >> > Something has changed ? >> >>>>> >> > > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > Fulvia now fails again , with different options >> >>>>> >> > > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > ./configure --enable-cxx && make -j 4 && make -j >> >>>>> >> > > >> >>>>> >> > 4 check >> >>>>> >> > > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > ranlib .libs/libmpir.a >> >>>>> >> > > >> >>>>> >> > rm -fr .libs/libmpir.lax >> >>>>> >> > > >> >>>>> >> > creating libmpir.la >> >>>>> >> > > >> >>>>> >> > (cd .libs && rm -f libmpir.la && ln -s >> >>>>> >> > > >> >>>>> >> > ../libmpir.la libmpir.la) /bin/bash ./libtool >> >>>>> >> > > >> >>>>> >> > --tag=CXX --mode=link g++ -O2 -m64 -march=core2 >> >>>>> >> > > >> >>>>> >> > -mtune=core2 -o libmpirxx.la -rpath >> >>>>> >> > > >> >>>>> >> > /usr/local/lib -version-info 4:4:1 dummy.lo >> >>>>> >> > > >> >>>>> >> > cxx/isfuns.lo cxx/ismpf.lo cxx/ismpq.lo >> >>>>> >> > > >> >>>>> >> > cxx/ismpz.lo cxx/ismpznw.lo cxx/osdoprnti.lo >> >>>>> >> > > >> >>>>> >> > cxx/osfuns.lo cxx/osmpf.lo cxx/osmpq.lo >> >>>>> >> > > >> >>>>> >> > cxx/osmpz.lo libmpir.la g++ -shared -nostdlib >> >>>>> >> > > >> >>>>> >> > /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o >> >>>>> >> > > >> >>>>> >> > /usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/gcc/ >> >>>>> >> > > >> >>>>> >> >i386-p c-s ol ar is2 .10/4. 4.0 /amd64/crtbegin.o >> >>>>> >> > > >> >>>>> >> > .libs/dummy.o cxx/.libs/isfuns.o >> >>>>> >> > > >> >>>>> >> > cxx/.libs/ismpf.o cxx/.libs/ismpq.o >> >>>>> >> > > >> >>>>> >> > cxx/.libs/ismpz.o >> >>>>> >> > > >> >>>>> >> > cxx/.libs/ismpznw.o >> >>>>> >> > > >> >>>>> >> > cxx/.libs/osdoprnti.o cxx/.libs/osfuns.o >> >>>>> >> > > >> >>>>> >> > cxx/.libs/osmpf.o cxx/.libs/osmpq.o >> >>>>> >> > > >> >>>>> >> > cxx/.libs/osmpz.o -Wl,--rpath >> >>>>> >> > > >> >>>>> >> > -Wl,/tmp/jason/.libs -Wl,--rpath >> >>>>> >> > > >> >>>>> >> > -Wl,/usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib >> >>>>> >> > > >> >>>>> >> > -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath >> >>>>> >> > > >> >>>>> >> > -Wl,/usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib >> >>>>> >> > > >> >>>>> >> > ./.libs/libmpir.so >> >>>>> >> > > >> >>>>> >> > -L/usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/gc >> >>>>> >> > > >> >>>>> >> >c/i386 -pc -s ol ari s2.10/ 4.4 .0/amd64 >> >>>>> >> > > >> >>>>> >> > -L/usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/gc >> >>>>> >> > > >> >>>>> >> >c/i386 -pc -s ol ari s2.10/ 4.4 .0/../../../amd64 >> >>>>> >> > > >> >>>>> >> > -L/lib/amd64 -L/usr/lib/amd64 >> >>>>> >> > > >> >>>>> >> > -L/usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/gc >> >>>>> >> > > >> >>>>> >> >c/i386 -pc -s ol ari s2.10/ 4.4 .0 >> >>>>> >> > > >> >>>>> >> > -L/usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/gc >> >>>>> >> > > >> >>>>> >> >c/i386 -pc -s ol ari s2.10/ 4.4 .0/../../.. >> >>>>> >> > > >> >>>>> >> > /usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/libs >> >>>>> >> > > >> >>>>> >> >tdc++. so -lm -lgcc_s >> >>>>> >> > > >> >>>>> >> > /usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/gcc/ >> >>>>> >> > > >> >>>>> >> >i386-p c-s ol ar is2 .10/4. 4.0 /amd64/crtend.o >> >>>>> >> > > >> >>>>> >> > /usr/lib/amd64/crtn.o -m64 -march=core2 >> >>>>> >> > > >> >>>>> >> > -mtune=core2 -Wl,-soname >> >>>>> >> > > >> >>>>> >> > -Wl,libmpirxx.so.3 -o .libs/libmpirxx.so.3.1.4 >> >>>>> >> > > >> >>>>> >> > /usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/libs >> >>>>> >> > > >> >>>>> >> >tdc++. so: could not read symbols: File in wrong >> >>>>> >> > > >> >>>>> >> > format collect2: ld returned 1 exit status >> >>>>> >> > > >> >>>>> >> > make[2]: *** [libmpirxx.la] Error 1 >> >>>>> >> > > >> >>>>> >> > make[2]: Leaving directory `/tmp/jason' >> >>>>> >> > > >> >>>>> >> > make[1]: *** [all-recursive] Error 1 >> >>>>> >> > > >> >>>>> >> > make[1]: Leaving directory `/tmp/jason' >> >>>>> >> > > >> >>>>> >> > make: *** [all] Error 2 >> >>>>> >> > > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > either I tested it wrong before or some paths >> >>>>> >> > > >> >>>>> >> > have changed on fulvia. The other thing I notice >> >>>>> >> > > >> >>>>> >> > is that it MUCH faster. >> >>>>> >> > > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > Jason >> >>>>> >> > > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > On Sunday 31 May 2009 12:37:55 Jason Moxham > wrote: >> >>>>> >> > > >> >>>>> >> >> fulvia passes all tests now >> >>>>> >> > > >> >>>>> >> >> >> >>>>> >> > > >> >>>>> >> >> On Sunday 31 May 2009 02:46:32 Jason Moxham > wrote: >> >>>>> >> > > >> >>>>> >> >> > I do a test run now and see if it passes with >> >>>>> >> > > >> >>>>> >> >> > that , why is fulvia so SLOW ?? takes about >> >>>>> >> > > >> >>>>> >> >> > an ~hour to build with 4 threads >> >>>>> >> > > >> >>>>> >> >> > >> >>>>> >> > > >> >>>>> >> >> > On Sunday 31 May 2009 02:28:28 Bill Hart > wrote: >> >>>>> >> > > >> >>>>> >> >> > > In that case it should be sufficient to >> >>>>> >> > > >> >>>>> >> >> > > pass CFLAGS=-m64 to configure. >> >>>>> >> > > >> >>>>> >> >> > > >> >>>>> >> > > >> >>>>> >> >> > > 2009/5/31 Jason Moxham >> >>>> >> >>>> <[email protected]>: >> >>>>> >> > > >> >>>>> >> >> > > > You are right >> >>>>> >> > > >> >>>>> >> >> > > > >> >>>>> >> > > >> >>>>> >> >> > > > when we select build=none we get ABI=long >> >>>>> >> > > >> >>>>> >> >> > > > not ABI=64 so that the compiler options >> >>>>> >> > > >> >>>>> >> >> > > > are none rather than -m64 this works with >> >>>>> >> > > >> >>>>> >> >> > > > gcc and cc on all other machines , sparc >> >>>>> >> > > >> >>>>> >> >> > > > Solaris included , darwin apple !!! >> >>>>> >> > > >> >>>>> >> >> > > > (shock horror) , just not on fulvia!!! >> >>>>> >> > > >> >>>>> >> >> > > > >> >>>>> >> > > >> >>>>> >> >> > > > On Sunday 31 May 2009 02:04:28 Bill Hart > wrote: >> >>>>> >> > > >> >>>>> >> >> > > >> Hopefully Mariah has some idea about >> >>>>> >> > > >> >>>>> >> >> > > >> this. I don't see why that wouldn't >> >>>>> >> > > >> >>>>> >> >> > > >> compile, except that perhaps it needs a >> >>>>> >> > > >> >>>>> >> >> > > >> -m64 or something like that. >> >>>>> >> > > >> >>>>> >> >> > > >> >> >>>>> >> > > >> >>>>> >> >> > > >> Bill. >> >>>>> >> > > >> >>>>> >> >> > > >> >> >>>>> >> > > >> >>>>> >> >> > > >> 2009/5/31 Jason Moxham >> >>>>> > >> >>>>> > <[email protected]>: >> >>>>> >> > > >> >>>>> >> >> > > >> > compiling >> >>>>> >> > > >> >>>>> >> >> > > >> > >> >>>>> >> > > >> >>>>> >> >> > > >> > int main (void) { return 0; } >> >>>>> >> > > >> >>>>> >> >> > > >> > >> >>>>> >> > > >> >>>>> >> >> > > >> > with >> >>>>> >> > > >> >>>>> >> >> > > >> > gcc crap.cc && ./a.out >> >>>>> >> > > >> >>>>> >> >> > > >> > is fine >> >>>>> >> > > >> >>>>> >> >> > > >> > >> >>>>> >> > > >> >>>>> >> >> > > >> > but >> >>>>> >> > > >> >>>>> >> >> > > >> > g++ crap.cc && ./a.out >> >>>>> >> > > >> >>>>> >> >> > > >> > libc.so.1: a.out: >> >>>>> >> > > >> >>>>> >> >> > > >> > fatal: >> >>>>> >> > > >> >>>>> >> >> > > >> > /usr/local/gcc-4.4.0/x86_64-SunOS-core >> >>>>> >> > > >> >>>>> >> >> > > >> >2/lib/ amd 64 /l ibs tdc++. so. 6: >> >>>>> >> > > >> >>>>> >> >> > > >> > wrong ELF class: ELFCLASS64 Killed >> >>>>> >> > > >> >>>>> >> >> > > >> > >> >>>>> >> > > >> >>>>> >> >> > > >> > which is what configure basically trys >> >>>>> >> > > >> >>>>> >> >> > > >> > to do >> >>>>> >> > > >> >>>>> >> >> > > >> > >> >>>>> >> > > >> >>>>> >> >> > > >> > not sure why it doesn't happen when we >> >>>>> >> > > >> >>>>> >> >> > > >> > just have --enable-cxx and no >> >>>>> >> > > >> >>>>> >> >> > > >> > build=none >> >>>>> >> > > >> >>>>> >> >> > > >> > >> >>>>> >> > > >> >>>>> >> >> > > >> > On Sunday 31 May 2009 01:44:57 Bill >> >>>>> >> > > >> >>>>> >> >> > > >> > Hart >> >>>> >> >>>> wrote: >> >>>>> >> > > >> >>>>> >> >> > > >> >> What does config.log say went wrong? >> >>>>> >> > > >> >>>>> >> >> > > >> >> >> >>>>> >> > > >> >>>>> >> >> > > >> >> 2009/5/31 Jason Moxham >> >>>>> >> >> >>>>> >> <[email protected]>: >> >>>>> >> > > >> >>>>> >> >> > > >> >> > ./configure --enable-cxx >> >>>>> >> > > >> >>>>> >> >> > > >> >> > --build=none fails on fulvia with >> >>>>> >> > > >> >>>>> >> >> > > >> >> > >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking build system type... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > none-none-none checking host system >> >>>>> >> > > >> >>>>> >> >> > > >> >> > type... none-none-none checking for >> >>>>> >> > > >> >>>>> >> >> > > >> >> > a BSD-compatible >> >>>>> >> > > >> >>>>> >> >> > > >> >> > install... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > /home/jasonmoxham/mpir/mpir/trunk/i >> >>>>> >> > > >> >>>>> >> >> > > >> >> >nstall -sh -c checking whether build >> >>>>> >> > > >> >>>>> >> >> > > >> >> > environment is sane... yes checking >> >>>>> >> > > >> >>>>> >> >> > > >> >> > for gawk... no checking for mawk... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > no >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking for nawk... nawk >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking whether make sets >> >>>>> >> > > >> >>>>> >> >> > > >> >> > $(MAKE)... yes checking whether to >> >>>>> >> > > >> >>>>> >> >> > > >> >> > enable maintainer-specific portions >> >>>>> >> > > >> >>>>> >> >> > > >> >> > of Makefiles... no checking >> >>>>> >> > > >> >>>>> >> >> > > >> >> > ABI=long checking compiler gcc -O3 >> >>>>> >> > > >> >>>>> >> >> > > >> >> > -DNO_ASM... yes checking for gcc... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > gcc checking for C compiler default >> >>>>> >> > > >> >>>>> >> >> > > >> >> > output file name... a.out checking >> >>>>> >> > > >> >>>>> >> >> > > >> >> > whether the C compiler works... yes >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking whether we are cross >> >>>>> >> > > >> >>>>> >> >> > > >> >> > compiling... no checking for suffix >> >>>>> >> > > >> >>>>> >> >> > > >> >> > of executables... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking for suffix of object >> >>>>> >> > > >> >>>>> >> >> > > >> >> > files... o checking whether we are >> >>>>> >> > > >> >>>>> >> >> > > >> >> > using the GNU C compiler... yes >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking whether gcc accepts -g... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > yes checking for gcc option to >> >>>>> >> > > >> >>>>> >> >> > > >> >> > accept ISO C89... none needed >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking for gcc option to accept >> >>>>> >> > > >> >>>>> >> >> > > >> >> > ISO C99... -std=gnu99 checking for >> >>>>> >> > > >> >>>>> >> >> > > >> >> > gcc -std=gnu99 option to accept ISO >> >>>>> >> > > >> >>>>> >> >> > > >> >> > Standard C... (cached) -std=gnu99 >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking how to run the C >> >>>>> >> > > >> >>>>> >> >> > > >> >> > preprocessor... gcc -std=gnu99 -E >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking build system compiler gcc >> >>>>> >> > > >> >>>>> >> >> > > >> >> > -std=gnu99... yes checking for >> >>>>> >> > > >> >>>>> >> >> > > >> >> > build system preprocessor... gcc >> >>>>> >> > > >> >>>>> >> >> > > >> >> > -std=gnu99 -E checking for build >> >>>>> >> > > >> >>>>> >> >> > > >> >> > system executable suffix... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking whether build system >> >>>>> >> > > >> >>>>> >> >> > > >> >> > compiler is ANSI... yes checking >> >>>>> >> > > >> >>>>> >> >> > > >> >> > for build system compiler math >> >>>>> >> > > >> >>>>> >> >> > > >> >> > library... -lm checking for g++... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > g++ checking whether we are using >> >>>>> >> > > >> >>>>> >> >> > > >> >> > the GNU C++ compiler... yes >> >>>>> >> > > >> >>>>> >> >> > > >> >> > checking whether g++ accepts -g... >> >>>>> >> > > >> >>>>> >> >> > > >> >> > yes checking C++ compiler g++ >> >>>>> >> > > >> >>>>> >> >> > > >> >> > -DNO_ASM -O3... no, program does >> >>>>> >> > > >> >>>>> >> >> > > >> >> > not run checking C++ compiler g++ >> >>>>> >> > > >> >>>>> >> >> > > >> >> > -DNO_ASM -g -O2... no, program does >> >>>>> >> > > >> >>>>> >> >> > > >> >> > not run configure: error: C++ >> >>>>> >> > > >> >>>>> >> >> > > >> >> > compiler not available, see >> >>>>> >> > > >> >>>>> >> >> > > >> >> > config.log for details >> >>>>> >> > > >> >>>>> >> >> > > >> >> > >> >>>>> >> > > >> >>>>> >> >> > > >> >> > The options works fine on thier own >> >>>>> >> > > >> >>>>> >> >> > > >> >> > >> >>>>> >> > > >> >>>>> >> >> > > >> >> > I've opened a trac ticket for this >> >>>>> >> > > >> >>>>> >> >> > > >> >> > This fails with the current >> >>>>> >> > > >> >>>>> >> >> > > >> >> > mpir-1.1.2 as well In case your >> >>>>> >> > > >> >>>>> >> >> > > >> >> > wondering why you may want >> >>>>> >> > > >> >>>>> >> >> > > >> >> > build=none , its to get all the >> >>>>> >> > > >> >>>>> >> >> > > >> >> > asserts for maximum debugging >> >>>>> >> > > >> >>>>> >> >> > > >> >> > >> >>>>> >> > > >> >>>>> >> >> > > >> >> > Jason >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
