You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Bala <e....@gmail.com> on 2006/03/23 12:34:07 UTC
Re: log4cxx build on SUN Solaris
> The library builds, but simplesocketserver fails to link due to
> unresolved symbols:
>
> unsigned log4cxx::helpers::UnicodeHelper::decodeWide(const wchar_t*&,const
> wchar_t*)
> int log4cxx::helpers::UnicodeHelper::encodeWide(unsigned,wchar_t*)
> int log4cxx::helpers::UnicodeHelper::lengthUTF8(wchar_t)
>
> log4cxx::pattern::FormattingInfo::FormattingInfo(const bool,const int,const
int)
> void log4cxx::pattern::FormattingInfo::format(const
> int,std::basic_string<char,std::char_traits<char>,std::allocator<char> >&)
const
>
> The first three seem to result from neither _WIN32 (natural on Solaris)
> nor __STDC_ISO_10646__ being defined in unicodehelper.cpp. Need to have
> a look at it.
I still see the problem of simplesocketserver failing to link in solaris 2.9 -
Forte CC 5.5 compiler, because of __STDC_ISO_10646__/_WIN32. Did someone have
a chance to look at this ?
-bala
Re: log4cxx build on SUN Solaris
Posted by Curt Arnold <ca...@apache.org>.
On Mar 23, 2006, at 5:34 AM, Bala wrote:
>> The library builds, but simplesocketserver fails to link due to
>> unresolved symbols:
>>
>> unsigned log4cxx::helpers::UnicodeHelper::decodeWide(const
>> wchar_t*&,const
>> wchar_t*)
>> int log4cxx::helpers::UnicodeHelper::encodeWide(unsigned,wchar_t*)
>> int log4cxx::helpers::UnicodeHelper::lengthUTF8(wchar_t)
>>
>> log4cxx::pattern::FormattingInfo::FormattingInfo(const bool,const
>> int,const
> int)
>> void log4cxx::pattern::FormattingInfo::format(const
>> int,std::basic_string<char,std::char_traits<char>,std::allocator<char
>> > >&)
> const
>>
>> The first three seem to result from neither _WIN32 (natural on
>> Solaris)
>> nor __STDC_ISO_10646__ being defined in unicodehelper.cpp. Need to
>> have
>> a look at it.
>
> I still see the problem of simplesocketserver failing to link in
> solaris 2.9 -
> Forte CC 5.5 compiler, because of __STDC_ISO_10646__/_WIN32. Did
> someone have
> a chance to look at this ?
>
> -bala
>
>
That is the symptom of wchar_t being defined, but no means of
determining the code set used by wchar_t. It appears that Korean and
Traditional Chinese Solaris define wchar_t (at least for some
functions) in terms of a character set other than Unicode, so the
compiler does not set __STDC_ISO_10646__. If those variants aren't
of interest, you can set __STD_ISO_10646__ or you can disable wide
builds using -Dhas.wchar_t=0.