--disable-nls vs. libiconv

Jeff Sturm jsturm@one-point.com
Sun May 11 15:30:00 GMT 2003


On 8 May 2003, Tom Tromey wrote:
> Jeff> The submitter makes a reasonable argument that gcj shouldn't try
> Jeff> to use iconv at all when configured with --disable-nls.  What do
> Jeff> others think?
>
> I thought --disable-nls was intended to turn off the gettext
> machinery...?

It does, but since gettext relies on iconv, some users have been building
with --disable-nls as a way to say "don't attempt to link with -liconv at
all".

> Jeff> a) looks like the current behavior, but I don't remember if this
> Jeff> was a deliberate choice or not.
>
> I don't think it was.  I don't remember thinking about --disable-nls
> at all.

I don't think gcj does anything with --disable-nls either, but since
configure detects libiconv regardless of --disable-nls, it gets linked to
jc1 anyway.

Some users were apparently surprised by this.  My finding is that they
are accustomed to problems bootstrapping with GNU libiconv, so they are
conditioned to using --disable-nls as a way to avoid linking with
-liconv, and it fails anyway in java.

I don't have a problem leaving it as-is, but I would like to fix the bug
in bootstrap/10657.  It's currently marked as a high-priority bug and
regression in 3.3.  I'd like to argue for downgrading the bug, based on my
findings:

- it is not a regression from 3.2
- there are several related bug reports not marked high-priority
- the configuration is a bit unusual, i.e. other testers could not
duplicate the problem based on the information given in the PR

Jeff



More information about the Java mailing list