[Bug java/11298] New: nl_langinfo (CODESET) handling

[mmokrejs at natur dot cuni dot cz]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11298

           Summary: nl_langinfo (CODESET) handling
           Product: gcc
           Version: 3.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mmokrejs at natur dot cuni dot cz
                CC: gcc-bugs at gcc dot gnu dot org

Hi,
  I'm sorry to post that late a bug report for ourtdated gcc-3.2.1 version, but
I believe someone finds time to reproduce with 3.3. I found this problem when
using configure generated in GNU gettext project. Here's the descriptiuon of the
bug explained by Bruno Haible, the developer of gettext. It happened on
Tru64Unix 5.1A(formerly OSF1). If you need test machine, create an account at
http://www.testdrive.hp.com and look for Tru64Unix. Here's the description of
problem from Bruno:

From: Bruno Haible <bruno@clisp.org>
To: Martin MOKREJS <mmokrejs@natur.cuni.cz>
Date: Mon, 24 Feb 2003 20:49:03 +0100 (CET)
Subject: Re: gettext: configure in current cvs

Hi,

> BTW, here is a bit more:
>   Actually, here are more details:
> 
> configure:3067: checking for Java to native code compiler
> configure:3090: found /software/@sys/usr/bin/gcj
> configure:3131: gcj  conftest.java --main=conftest -o conftest
> conftest.java:0: unknown encoding: `ISO8859-1'
>    This might mean that your locale's encoding is not supported
>    by your system's iconv(3) implementation.  If you aren't trying
>    to use a particular encoding for your input file, try the
>    `--encoding=UTF-8' option
> compilation terminated.
> configure:3134: $? = 1
> configure:3150: result: none
> 
> $ /software/@sys/usr/bin/gcj --version
> gcj (GCC) 3.2.1

Looking at the sources of gcc-3.2.1/gcc/java/lex.c, we see:

#if defined (HAVE_LOCALE_H) && defined (HAVE_ICONV) && defined (HAVE_NL_LANGINFO)
            setlocale (LC_CTYPE, "");
            if (encoding == NULL)
              encoding = nl_langinfo (CODESET);
#endif
            if (encoding == NULL || *encoding == '\0')
              encoding = DEFAULT_ENCODING;

            java_init_lex (finput, encoding);

I.e. gcc assumes that the 'nl_langinfo (CODESET)' result can be passed
to iconv(). Now this is "ISO8859-1", which is a nonstandard encoding
name, and libiconv - which is your iconv implementation in this - case,
doesn't understand it.

The 'localcharset' module in gnulib solves this problem; it would have
to be integrated into gcc.