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:[email protected]]
Sent: Monday, December 07, 2015 22:42 PM
To: troy <[email protected]>; APR Developer List <[email protected]>
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 <[email protected]
<mailto:[email protected]> > 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 ✌
