apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: why apr_arch_utf8.h does not use extern "C" to export symbols for C++ user
Date Mon, 07 Dec 2015 14:42:27 GMT
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?



On Mon, Dec 7, 2015 at 5:30 AM, troy <troy@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   ✌

View raw message