On 08/13/2012 08:47 PM, Dennis Clarke wrote: > > > ----- Original Message ----- > From: Stefano Lattarini <stefano.lattar...@gmail.com> > Date: Monday, August 13, 2012 8:21 am > Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc > To: Dennis Clarke <dcla...@blastwave.org> > Cc: 12...@debbugs.gnu.org > > >> On 08/13/2012 01:46 AM, Dennis Clarke wrote: >>> >>> At least I can get results in one hour now. :-\ >>> >>> [SNIP] >>> >> Same as before: the only actual failure is: >> >> FAIL: t/silent-many-generic >> =========================== >> >> ... >> + make >> ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32 >> ld: fatal: file processing errors. No output written to baz >> make: Fatal error: Command failed for target `baz' >> >> which seems to suggest your C++ linker has issues linking together >> objects generated by your C++ compilers with objects generated by >> your Fortran 90 compiler. Could you try whether/how the same issue >> is present outside the Automake testsuite? >> > > before I climb into that, I notice on configure output this : > > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... no > checking whether /opt/SUNWspro/bin/cc accepts -g... yes > checking for /opt/SUNWspro/bin/cc option to accept ISO C89... none needed > checking whether the C++ compiler works... yes > checking for C++ compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C++ compiler... no > checking whether /opt/SUNWspro/bin/CC accepts -g... yes > checking for xlf95... no > checking for f95... f95 > checking whether the Fortran compiler works... yes > checking for Fortran compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU Fortran compiler... no > checking whether f95 accepts -g... yes > checking for xlf... no > checking for f77... f77 > checking whether the Fortran 77 compiler works... yes > checking for Fortran 77 compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU Fortran 77 compiler... no > checking whether f77 accepts -g... yes > configure: will now look for GNU compilers > checking for gcc... no > configure: WARNING: botched installation for GNU C compiler > configure: tests requiring the GNU C compiler will be skipped > checking for g++... no > checking for gpp... no > configure: WARNING: botched installation for GNU C++ compiler > configure: tests requiring the GNU C++ compiler will be skipped > checking for gfortran... no > configure: WARNING: botched installation for GNU Fortran compiler > configure: tests requiring the GNU Fortran compiler will be skipped > checking for g77... no > checking for gfortran... no > configure: WARNING: botched installation for GNU Fortran 77 compiler > configure: tests requiring the GNU Fortran 77 compiler will be skipped > checking for gcj... no > configure: WARNING: botched installation for GNU Java compiler > configure: tests requiring the GNU Java compiler will be skipped > checking that generated files are newer than configure... done > configure: creating ./config.status > > > Is there some reason why GNU Fortran is a "need" ? > Only to run some tests. That's why the configure script merely warn if that compiler (or any of other ones, in fact) is missing: they are not actually required to build and use Automake, but only to run its testsuite properly.
> Also, Java compiler, I think Solaris includes a really top notch > Java compiler in /usr/jdk/latest . > That might be useful for the generic java tests (those checking the JAVA primary), and those tests will automatically look for the presence a 'java' and 'javac' programs in PATH at test runtime, without a need for configure-time checks. But some other test cases actually target compilation into native object code with gcj; they are not meant to work with generic Java compiler, however good those might be. HTH, Stefano
