I am not sure if this is related to this problem, but here is an observation:
All config.sub scripts from rtems' intrastructure packages internally
transform i386-rtems into i386-pc-rtems
newlib-1.8.0-rtems/config.sub i386-rtems --> i386-pc-rtems
egcs-1.0/config.sub i386-rtems ---> i386-pc-rtems
egcs-1.0.1/config.sub i386-rtems ---> i386-pc-rtems
bintutils-2.8.1.0.19/config.sub i386-rtems ---> i386-pc-rtems
gas-98xxxx/config.sub i386-rtems ---> i386-pc-rtems
The only exception is rtems itself:
rtems/config.sub i386-rtems ---> i386-rtems
I am not sure if this influences i386-rtems + c++/posix, but this indicates
that rtems' config.sub script should to be updated.
To fix this, simply copying config.sub e.g. from egcs and removing all
i[3456]-rtems* case statement lines from configure.in should be sufficient.
BTW, from autoconf's point of view i386-pc-rtems is the correct target
conforming autoconf's naming conventions, but using i386-rtems for all
packages (infrastructure and rtems) should make no difference.
> RTEMS is under CVS control and has been since rtems 3.1.16 which was
> around May 1995. So I just to add the $Id$. If you notice other files
> with missing $Id$'s let me know. I try to keep w\up with it.
Now that you have asked -- I'll attach a list of files lacking an RCS-Id to
this mail. This list has been generated by a little sh-script I'll also
enclose.
GNU autoconf. This is the first large step in allowing an RTEMS
user to perform a one-tree build (per crossgcc FAQ) including RTEMS
in the build process. With this change RTEMS is configured in
built in the same style as the GNU tools, yet retains the basic
structure of its traditional Makefiles (ala Tony Bennett).
Jiri Gaisler (jgais@wd.estec.esa.nl) deserves (and received)
a big thank you for doing this.
There are still issues to be resolved but as of this commit, all target
which can be built on a linux host have been using a modified version
of the source Jiri submitted. This source was merged and most targets
built in the tree before this commit.
There are some issues which remain to be resolved but they are primarily
related to host OS dependencies, script issues, the use of gawk
for hack_specs, and the dependence on gcc snapshots. These will
be resolved.
