>grep GB2312 * >cd include/libxml2 >grep GB2312 * >Nothing shown with GB2312. >Nothing with EUC-CN either. >Please help!
Agreed with Daniel, that doesn't make sense ;-) >My libiconv also has GB2312. But my libxml2 does not have GB2312. >Frank Peng. Your libxml2 does not need GB2312. But libxml2 needs to use the libiconv that you provide. The problem *might* be of a sort that I experienced some time ago and it might be of interest to Daniel, too (that's why I even reply here): The libiconv binding in libxml2 may fall back to the default OS iconv() implementation instead of using the explicit libiconv() functions. Compiling your own libiconv and telling it to the configure option of libxml2 is not enough. If the OS provides its own iconv() implementation, libxml2 will use that one at runtime and you will not have the additional encodings (such as GB2312 in this case). That is because libC is typically linked to your binary and libC already contains iconv() symbols, but not that many encodings (depending on OS and packages installed). So what can you do? Force libxml2 to your own libiconv() functions, not the iconv() implementation of the OS. This can be done two ways. Version 1: Changing the iconv() calls of libxml2 to specific libiconv() calls and force the "iconv.h" to include the local include file of libiconv. Version 2: Use the libiconv plug and preload it for your application so that the iconv() calls are overloaded and directed to the libiconv instead of the OS iconv() implementation. To check if this is actually your problem, truss/trace your process and check which iconv() function is used by libxml2. If this is your problem, you will see jumps into iconv() of libC instead of libiconv. Best regards Cyrill _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
