This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wed, Sep 04, 2002 at 02:17:19AM -0300, Alexandre Oliva wrote:
> On Sep  1, 2002, Jakub Jelinek <> wrote:
> > 2002-09-01  Jakub Jelinek  <>
> > 	* 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?

I'm fine with #1, but can't we come up with a link test that is "good
enough" to establish appropriate glibc version?

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]