Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

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 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

Detailed analysis (so I can point to it in a mail to config-patches at

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
  # else
  # endif
  # else
  # endif
  #ifdef __dietlibc__

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)

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

The issue may be worked around by passing
to the configure invocation.


[1] wget \ \