Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Ralf Wildenhues (Ralf.Wildenhues_at_[hidden])
Date: 2005-12-03 10:30:03


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