Curt Arnold wrote:
>> the attached patch fixes the UTF8 build on unix.
[...]
> What was the nature of the compile failures? Was it on a specific
It was the localechar being defined as wchar_t on Linux:
#if LOG4CXX_HAS_STD_WLOCALE && LOG4CXX_HAS_WCHAR_T
typedef wchar_t localechar;
#define LOG4CXX_LOCALE_STR(str) L ## str
#else
...
but the LogString is of course defined as std::string
for UTF8 compile. Then, assignments from LogString to
basic_string<localechar>& failed when calling the
PatternToken::format() method.
> platform or had their been changes that introduced the failure? Gump
> may no longer be building log4cxx since apr-util has had a build
> failure for a month.
Would it be possible to re-activate the gump build? I am executing
a nightly automake based build with both logchar=wchar_t and
logchar=utf-8, but I think an ant based build on another system
would be useful for regression. My build already runs for almost
2 hours ...
[...]
> class in the header file. Seems like a good change to me and I don't
> recall why I did it like that in the first place.
For my own sources, I stopped asking myself this kind of questions
some time ago ;-)
Thanks,
Andreas
