libstdc++/3174: sparc-rtems (also seen on i386-rtems)
Benjamin Kosnik
bkoz@redhat.com
Thu Jun 14 14:50:00 GMT 2001
Hmm. I still have the feeling that you and I are looking at different
pieces of code.
Here's what I am looking at:
dnl
dnl Check to see if g++ can compile this library, and if so, if any version-
dnl specific precautions need to be taken.
dnl
dnl GLIBCPP_CHECK_COMPILER_VERSION
AC_DEFUN(GLIBCPP_CHECK_COMPILER_VERSION, [
if test ! -f stamp-sanity-compiler; then
AC_MSG_CHECKING([for g++ that will successfully compile libstdc++-v3])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE(, [
#if __GNUC__ < 3
not_ok
#endif
], gpp_satisfactory=yes, AC_MSG_ERROR([please upgrade to GCC 3.0 or
above]))
AC_LANG_RESTORE
AC_MSG_RESULT($gpp_satisfactory)
touch stamp-sanity-compiler
fi
])
This is called after GLIBCPP_CONFIGURE(.) in configure.in.
GLIBCPP_CONFIGURE correctly sets CXX, which AC_TRY_COMPILE then uses to
try this test.
It's my understanding that CPP is not even an issue.
Again, this is working quite well for me for x86-x-powerpc-eabism crosses
on a system with a /usr/bin/g++ that is not 3.0. I have no problems. I
suspect that either the rtems bits are doing something funky, you are
trying to build in previously-configured trees, or I there is something I
really don't get and that you've failed to explain to me.
Please make sure we are talking about the same codebase. Also, can you
try completely removing your build directory's (target)/libstdc++-v3
directory and starting before starting the top-level make?
thanks,
benjamin
> Remember the problem is not the version test itself -- it is the fact
> that the
> wrong CPP is being used -- the native instead of the cross one. All other
> tests use the cross compiler.
More information about the Gcc-bugs
mailing list