This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Solaris -vs- iconv
- To: Jeff Sturm <jsturm at one-point dot com>
- Subject: Re: Solaris -vs- iconv
- From: Tom Tromey <tromey at redhat dot com>
- Date: 30 Mar 2001 18:20:49 -0700
- Cc: java at gcc dot gnu dot org
- References: <Pine.LNX.4.10.10103261550370.9543-100000@mars.deadcafe.org>
- Reply-To: tromey at redhat dot com
>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
Jeff> It seems that Solaris iconv understands all of ISO8859-1, UTF-8,
Jeff> UCS-2/UTF-16 and plain ASCII just fine. The problem is that it
Jeff> cannot translate between arbitrary combinations of those :(
In that case I think we should simply declare the Solaris iconv()
nonfunctional and disable support for it.
Jeff> 1) Hack libjava.exp for --encoding.
We should do this regardless of how we fix the Solaris problem. If we
don't do this then the user's locale could mess up test results.
Jeff> But since this isn't needed for glibc, I wonder if Solaris is
Jeff> really the special case? Does anybody use iconv on any other
Jeff> platforms?
I haven't looked to see if any other platforms implement iconv() at
all.
Another option would be to support something like invoking recode via
popen when iconv() is known to lose (provided we failed gracefully if
recode wasn't available). Then the encoding failure error message
could have a link to some java web page mentioning this feature and
saying how to install recode. Doing this definitely isn't a priority
for me.
Tom