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
