Wow, several bugs for the price of one report. :) * Jeff Squyres wrote on Sat, Nov 26, 2005 at 08:24:33PM CET: > On Nov 25, 2005, at 4:03 PM, Galen M. Shipman wrote: > > > On a fresh co of the trunk, after a successful autogen.sh I get the > > following error with this configure: > > > > ./configure CC=pgcc CXX=pgCC F77=pgf77 FC=pgf90 --disable-io-romio - > > with-mvapi=/usr/local/ib --enable-static --disable-shared --prefix=/u/ > > gshipman/myapps > > > > *** Initialization, setup > > configure: builddir: /u/gshipman/ompi_pgi > > configure: srcdir: /u/gshipman/ompi_pgi > > checking build system type... Invalid configuration > > `x86_64-unknown-linux-': machine `x86_64-unknown-linux' not recognized > > configure: error: /bin/sh ./config/config.sub x86_64-unknown-linux- failed
> > Not sure what is going on here, Jeff fixed this for me one other time > > but I am not sure what magic he did, this is occurring on odin. > > All I did was re-run autogen for you with my own copies of the Auto > tools. I think the difference was that I had the most most most recent > version of Libtool (i.e., I don't use the system-installed auto tools > on odin). I stumbled over this myself now. It's due to an old version of `config.guess'. With a current version of the config.* scripts[1], things seem to work, but the underlying bugs are merely not exposed any longer, not fixed. In any case, I'd recommend updating the systems' various copies of the config.* scripts (the installed ones date 2005-03-24). Detailed analysis (so I can point to it in a mail to config-patches at gnu.org): First, in some cases, config.guess executes eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=` with $dummy.c containing this (modulo leading white space): #include <features.h> #ifdef __ELF__ # ifdef __GLIBC__ # if __GLIBC__ >= 2 LIBC=gnu # else LIBC=gnulibc1 # endif # else LIBC=gnulibc1 # endif #else #ifdef __INTEL_COMPILER LIBC=gnu #else LIBC=gnuaout #endif #endif #ifdef __dietlibc__ LIBC=dietlibc #endif Now the eval line above contains two flaws: First, it may screw up the newlines in the output of the command substitution: the eval will evaluate something like # 1 "a.c" # 1 "<built-in>" # 1 ... LIBC=gnu (abbreviated output with GCC) and thus $LIBC will not be set. This may be fixed by double-quoting the `...` part. Second, the preprocessor has the right to introduce spacing at token boundaries, and pgcc will do just that: # 1 "a.c" # 1 "/usr/include/features.h" ... LIBC = gnuaout An earlier version of the script correctly included provision for this: | eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep LIBC= | sed -e 's: ::g'` We may remove the grep, and fix the quoting issue, although not strictly necessary any more in this version, arriving at eval "`$CC_FOR_BUILD -E $dummy.c 2>/dev/null | sed -n '/LIBC/{s: ::g;p;}'`" (Several occasions of the same bugs exist in the script.) Third, and this can be seen from the output of the second version, there is another bug looming with pgcc: it will output gnuaout, wrongly. Now, this is because pgcc doesn't predefine __ELF__. This may be handled similarly to the Intel compiler case: #if defined(__INTEL_COMPILER) || defined(__PGI) LIBC=gnu #else The reason why newer config.guess scripts do not exhibit the issue (on the x86_64 system in question) is that, for x86_64 the `eval' command is not executed any more. However, AFAIK the 32bit version of pgcc does not define __ELF__ either, so potentially on x86 this issue may still be open. The issue may be worked around by passing --build=x86_64-unknown-linux-gnu to the configure invocation. Cheers, Ralf [1] wget \ http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/config/config/config.sub \ http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/config/config/config.guess