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