bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Small problems with gettext 0.11 on Solaris


From: Drazen Kacar
Subject: Small problems with gettext 0.11 on Solaris
Date: Sat, 2 Feb 2002 07:50:00 +0100

Hello,

I've tried compiling gettext 0.11 and "make check" failed for several
tests. The iconv() implementation is Solaris 8 native, but with a custom
"configuration," so I don't know how many tests would fail with
out-of-the-box system.

The first class of problematic checks looks like this:

msgcat: mcat-test2.in2: warning: Charset "UTF-8" is not supported. msgcat relies
on iconv(),
PASS: msgcat-2
msgcat: mcat-test3.in2: warning: Charset "UTF-8" is not supported. msgcat relies
on iconv(),
PASS: msgcat-3
msgcat: mcat-test4.in1: warning: Charset "UTF-8" is not supported. msgcat relies
on iconv(),


The first thing to note is that the warning message might stand some
improvement. Solaris does support UTF-8, but it's questionable if the
level of support is good enough for GNU gettext. However, the meaningful
message should include both charset names which were passed to
iconv_open() and not just one.

Upon investigation in the debugger, I've found that the attempted
conversion was from UTF-8 to UTF-8. Solaris iconv_open() will indeed
return an error if one attempts this. I could cure the problem on my side,
but I'm wondering if you would be interested in checking for this case in
the gettext code (function po_lex_charset_set in po-charset.c printed the
warning). There isn't much point in the overhead caused by unnecessary
calling iconv() in this case.

I also got a bunch of similar messages from the plural-1 test saying that
charset ASCII was not supported (but without specifying the other charset
in the conversion). I haven't looked closely, but I suppose the problem
has the same source.

The second problem is that msgconv-1 invoked abort() in msgconv utility,
but that looks like a Solaris bug.

The next problem is that msgcomm-4, msgcomm-5, msgcomm-6 and msgcomm-7
fail because iconv() doesn't handle conversion from ASCII to ISO-8859-1.
It does not, because ASCII is not a valid input character set name. This
looks serious enough, so I'll do something about it. But could you tell me
how msgcomm came to the conclusion that it needs to perform the conversion
from ASCII to ISO-8859-1 (or anything else)? The catalogs in the test
files specify iso-8859-1 for charset, so I'm not quite sure where ASCII
comes into picture.

-- 
 .-.   .-.    I don't think for my employer.
(_  \ /  _)
     |        address@hidden
     |



reply via email to

[Prev in Thread] Current Thread [Next in Thread]