Thanks for you quick reply, William.
On windows, I built apr from apr.dsw with vs2010. The functions “apr_conv_utf8_to_ucs2” and “apr_conv_ucs2_to_utf8” are exported by default. That is because they are declared with APR_DECLARE(apr_status_t). They can be found and imported when modifying the header by adding extern “C” or tricking as bellow. #ifdef WIN32 extern "C" { #include "arch/win32/apr_arch_utf8.h" }; #endif //WIN32 My team is developing a file-sharing app running on all platforms. APR is our top candidate OSAL library. I happened to find these two APIs when I was studying file IO APIs. In fact we not only need to fopen Unicode(wchar_t* on windows) and utf-8(on *nix) , but also want to send a file name between windows and android. That is the scenario to require the conversion APIs. Troy Represents Oh Yeah ✌ From: William A Rowe Jr [mailto:wr...@rowe-clan.net] Sent: Monday, December 07, 2015 22:42 PM To: troy <t...@limaoso.com>; APR Developer List <dev@apr.apache.org> Subject: Re: why apr_arch_utf8.h does not use extern "C" to export symbols for C++ user Yes, because include/arch/ and include/private were always intended to be private details and those headers are not going to be installed by default when you 'make install'. Since then it seems there are a lot of consumers of these sorts of headers, I believe tcnative needs a few of these. If we determine that apr_conv_utf8_to_ucs2 should be public, they would become part of the apr_xlate_ API and we would decorate the headers appropriately. At the start, apr on win32 needed this behavior; apr_xlate exists in apr-util, too late for the core apr library to consume. Now in 2.0 we have merged apr, apr-util into a single entity, so this is no longer an issue. Curious what led you to need these functions, so that we can consider if they should be exported? Cheers, Bill On Mon, Dec 7, 2015 at 5:30 AM, troy <t...@limaoso.com <mailto:t...@limaoso.com> > wrote: Hi all, There are some header files not in include/arch folder, say include\arch\win32\apr_arch_utf8.h. The symbols “apr_conv_utf8_to_ucs2” and “apr_conv_ucs2_to_utf8” are not embraced with extern “C”. It gives me trouble to locate the symbols. Is it a bug? Troy Represents Oh Yeah ✌