Some configures in /cvs/src needs regeneration with autoconf

[Michael Matz]

Hi,

I was following Geoff Keatings advices to build a simulated test
environment (the target in this case was d30v-elf), and after configuring
gdb failed to build.  The inherent reason is that some of the configure
files involved for this target are still as generated with autoconf 2.10.
This leads to corruption of the cache file.

For those interested: before one of these files get invoked config.cache
has entries similar to that: "ac_cv_prog_CPP=${ac_cv_prog_CPP=$'gcc -E'}"
If the 2.10 files gets the chance to read/write this cache-file they
convert this to "ac_cv_prog_CPP=${ac_cv_prog_CPP=$'$gcc -E'}", which later
in all other configure files leads to $gcc being used as $CPP, which
then of course fails to run (The case at hand was, that poll() support was
detected, but neither <poll.h> nor <sys/poll.h> were included, because
configure thought they were not there).

The 2.10 files in my checked out /cvs/src (I may be have not got
everything, only what is needed for the modules binutils, newlib, dejagnu
and gdb) are:

./sim/testsuite/d30v-elf/configure
./libgloss/m68k/configure
./libgloss/pa/configure
./libgloss/hp74x/configure
./libgloss/sparc/libsys/configure
./libgloss/m32r/configure
./utils/sparclite/configure

(And indeed regenerating the d30v-elf one, the build went on, until the
cc1 is segfaulting itself ;) )

Some others are still 2.12.1, but this is OK (at least in this respect).

So, and this is the reason for the above two addresses I sent this mail.
I'm not sure to whom these files belong, but hope to reach by this way at
least one person having global write privs, which can just regenerate
these files.


Ciao,
Michael.