This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch: configure -vs- iconv

>>>>> "Benjamin" == Benjamin Kosnik <> writes:

Benjamin> now that i look at 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]