I wonder why you declare apr_int64_t in log4cxx-headers. apr_int64_t is defined in apr_atomic.h, so if you need it, include this header.


I've avoided including APR headers in the log4cxx headers to eliminate the need for applications that are using log4cxx to have to add APR to their include path. I'm able to use forward declarations for apr_pool_t, apr_iconv_t and others. I'll review the definition for apr_int64_t, but I'll resort to some other mechanism to forward declare it before including APR headers in log4cxx headers.

I changed apr_time_t and apr_int64_t headers to log4cxx_time_t and log4cxx_int64_t and made definitions that should hopefully be 64-bit or larger integers. In the implementation these should be assignment compatible with apr_time_t and apr_int64_t but should avoid the inconsistent declaration errors and avoids requiring apr to be in the include path for applications using log4cxx.

Win32 is almost building. I need to fill in implementations for mbsnrtowcs and wcsnrtombs and am getting unexpected messages that StringHelper::toString(int, apr_pool_t*) is missing.

Reply via email to