This is the mail archive of the
mailing list for the GCC project.
Re: Patch: configure -vs- iconv
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: Patch: configure -vs- iconv
- From: Tom Tromey <tromey at cygnus dot com>
- Date: 13 Sep 2000 19:50:37 -0600
- Cc: gcc-patches at gcc dot gnu dot org
- References: <Pine.SOL.3.91.1000913132033.6586Aemail@example.com>
- Reply-To: tromey at cygnus dot com
>>>>> "Benjamin" == Benjamin Kosnik <firstname.lastname@example.org> writes:
Benjamin> now that i look at it...you never check for
Benjamin> iconv.h.... you'll definitely need to do this........
Yeah, I suppose so. Right now the code just assumes that if we have
iconv() then we must have iconv.h. That is probably losing. I'll
send a patch.
Benjamin> anyway. I ask about this because it looks like the
Benjamin> signatures change between glibc2.1.x and glibc2.2 (or
Benjamin> between RH 6.2 and RH 7.0, in particular.) The RH 7
Benjamin> signatures are correct.
Benjamin> Are you adding checks for this?
>> For the runtime, what we do is fall back to trying iconv if no
>> built-in charset conversion class exists.
Benjamin> by "built-in charset conversion class" you mean the stuff
Benjamin> based on ISO C9X, ie wmemcmp, et al? (This seems unlikely)
Benjamin> Or, what?
We make it possible to write a charset converter in Java. If you
write a subclass of gnu.gcj.convert.UnicodeToBytes (or
gnu.gcj.convert.BytesToUnicode) and put it into the gnu.gcj.convert
package, then the conversion lookup functions will automatically use
that class -- these functions work by using reflection to find a class
implementing the conversion, and, if none is found, the iconv-based
fallback is tried.
Benjamin> Kay. (You are using UCS-2 instead of UNICODE for iconv_open?)
Ok, this seems to be related to what I want to know, but not exactly
on target. ISTR that the things I want to know haven't really been
decided yet. Perhaps I'll just wait until the new C++ ABI is done and
then pick up the pieces from there.