[PATCH] Fix libstdc++ usage of __ctype_b/__ctype_to*

[Alexandre Oliva]

On Sep  1, 2002, Jakub Jelinek <jakub@redhat.com> wrote:

> 2002-09-01  Jakub Jelinek  <jakub@redhat.com>

> 	* config/os/gnu-linux/bits/ctype_noninline.h
> 	(ctype<char>::classic_table): If _GLIBCPP_C_LOCALE_GNU, return
>       _S_c_locale-> __ctype_b, otherwise temporarily switch to "C" locale
> 	and return __ctype_b.
> 	(ctype<char>::ctype(__c_locale, const mask*, bool, size_t)): If not
> 	_GLIBCPP_C_LOCALE_GNU, temporarily switch to "C" locale and
> 	initialize using __ctype_{b,tolower,toupper}.
> 	(ctype<char>::ctype(const mask*, bool, size_t)): If
> 	_GLIBCPP_C_LOCALE_GNU, initialize using
>       _S_c_locale-> __ctype_{b,tolower,toupper}, otherwise temporarily
> 	switch to "C" locale and initialize using __ctype_{b,tolower,toupper}.

FWIW, this is not enough to get a cross toolchain to build properly
using a CVS version of glibc.  The problem is this chunk of code in
libstdc++-v3/acinclude.m4:

	# Test for bugs early in glibc-2.2.x series
  	if test x$enable_clocale_flag = xgnu; then
    	  AC_TRY_RUN([
[...]
	  [enable_clocale_flag=gnu],[enable_clocale_flag=generic],
	  [enable_clocale_flag=generic])

See, when cross compiling, AC_TRY_RUN ends up running the last
command, i.e., it makes the conservative assumption that
enable_clocale_flag=generic should be used.  However, with the CVS
version of glibc, generic just doesn't work any longer, since there's
no such thing as __ctype_b any longer.

I have two proposals to solve the problem:

1) assume whoever is clueful enough to build a cross toolchain for a
   gnu-linux-targeted system knows better than using an old, broken
   glibc, and set enable_clocale_flag=gnu in the cross-compiling case,
   or

2) introduce an earlier test that checks whether glibc is say 2.2.??
   or newer (does anyone know the version in which the bugs mentioned
   in that test were fixed), and forces enable_clocale_flag=gnu in
   that case.

I don't like testing for version numbers in autoconf tests, and I
think the assumption in the first proposal is quite reasonable, but if
someone feels really paranoid about not making non-fool-proof
assumptions like that, I could implement #2.  Comments?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer