This seems like an obvious question, but I haven't been able to find much about in the documentation, FAQs, or mailing list archives.
For GNU/Linux, why would one choose the iconvGNU transcoder over the native transcoder or the other way around? I'm maintaining the Debian GNU/Linux xerces-c packages these days. These packages provide two versions of the libraries: a default one that uses the iconvGNU transcoder, and an alternative that uses the ICU transcoder. I'm trying to decide whether to replace the default one with a build that uses the native transcoder, to leave things alone, or to add an additional alternative. I notice the include RPM .spec file uses the native transcoder. There is one bug filed against the debian package that seems to be traced to the GNU transcoder and is not present in the native transcoder, and there are compilation errors when building IconvGNUTransService.cpp with gcc 3.3 (which I'll report in Jira if they haven't already been reported), which may suggest that xerces-c developers don't use this trancoder very much. For what it's worth, it seems clear that the ICU transcoder offers some functionality advantages over the other transcoders since more encodings are supported. I've heard but have not independently verified that it is also slower. This along with the additional dependencies seems like a good enough reason to make this option easily available but not the default. Thanks for any clarification you can provide. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
