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