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/gcc/i386 >>>>> >> > > >> >>>>> >> >-pc -s ol ari s2.10/ 4.4 .0/amd64 >>>>> >> > > >> >>>>> >> > -L/usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/gcc/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/gcc/i386 >>>>> >> > > >> >>>>> >> >-pc -s ol ari s2.10/ 4.4 .0 >>>>> >> > > >> >>>>> >> > -L/usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/gcc/i386 >>>>> >> > > >> >>>>> >> >-pc -s ol ari s2.10/ 4.4 .0/../../.. >>>>> >> > > >> >>>>> >> > /usr/local/gcc-4.4.0/x86_64-SunOS-core2/lib/libstdc++. >>>>> >> > > >> >>>>> >> >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/libstdc++. >>>>> >> > > >> >>>>> >> >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-core2/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/install >>>>> >> > > >> >>>>> >> >> > > >> >> >-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 -~----------~----~----~----~------~----~------~--~---
