This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix libstdc++ usage of __ctype_b/__ctype_to*
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Ulrich Drepper <drepper at redhat dot com>,Roland McGrath <roland at redhat dot com>, bkoz at redhat dot com,pcarlini at unitus dot it, libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 4 Sep 2002 12:17:45 -0400
- Subject: Re: [PATCH] Fix libstdc++ usage of __ctype_b/__ctype_to*
- References: <20020901034451.G7886@dhcp187.sf.frob.com> <20020901065254.B7920@devserv.devel.redhat.com> <20020901040933.I7886@dhcp187.sf.frob.com> <20020901095711.C7920@devserv.devel.redhat.com> <20020901102055.A5791@devserv.devel.redhat.com> <3D724B9A.6050908@redhat.com> <20020901145657.E7920@devserv.devel.redhat.com> <3D726A72.2080106@redhat.com> <20020901165440.F7920@devserv.devel.redhat.com> <or4rd6nxk0.fsf@free.redhat.lsd.ic.unicamp.br>
On Wed, Sep 04, 2002 at 02:17:19AM -0300, Alexandre Oliva wrote:
> 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?
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