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 Andreas Fester <af...@apache.org> on 2005/12/15 14:30:20 UTC
log4cxx build on SUN Solaris
Hi,
the latest tarball from
http://www.littletux.net/log4cxx/log4cxx-0.9.8.tar.gz
is now compilable on Solaris (I verified it on Solaris 2.9
with gcc 3.3). The test cases also execute properly.
The main changes were to fix the detection of std::wstring
instead of wchar_t, to wrap some pieces of code which use
wstring with the appropriate #ifdefs and to get rid
of the non-portable linker options when creating the test
suite.
I still have to adjust the build.xml so that the result
is the same regarding the testsuite shared library,
then I will commit the patches.
Regards,
Andreas
Sherbert, Stephen wrote:
> After further investigation, it turns out that since the C99 C++
> standard is not 100% adhered to on Solaris, the configure scripts for
> building gcc disable wide character support. As a result, I cannot
> build log4cxx with wide character support on Solaris without building a
> new gcc with a few tweaks.
[...]
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.
Re: log4cxx build on SUN Solaris
Posted by Bala <e....@gmail.com>.
> 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 Andreas Fester <af...@apache.org>.
>> Is it unbearably hard to make the automake build to create a single
>> test executable without using an intermediate library? Breaking the
>> test suite up into a small driver and a shared library of tests has got
>> to make debugging in some IDE's more complicated than just having a
>> single test executable.
Ok, I have now adjusted the automake build for the test
suite to the ant approach. The ant build simply collects all
.cpp files below tests/src/** and directly links the object files to
one executable, without creating static archive libraries for each
sub directory. I think this is a proper approach; some hints
on cppunit also say not to use (static) libraries with cppunit,
due to similar problems.
If there are no objections, I will commit this ...
Best Regards,
Andreas
Re: log4cxx build on SUN Solaris
Posted by Chris Williams <ch...@yahoo.com>.
You can now get Sun Studio 11 from Sun for free from their website. A few months ago, I tired to compile with Sun Studio 10 and documented my findings to the mailing list. I am hoping to get back on my Sun box to help put with this task since we are looking to use log4cxx in a project soon.
Chris
----- Original Message ----
From: Andreas Fester <af...@apache.org>
To: Log4CXX User <lo...@logging.apache.org>; Log4CXX Dev <lo...@logging.apache.org>
Sent: Friday, December 16, 2005 05:49:52
Subject: Re: log4cxx build on SUN Solaris
Curt Arnold wrote:
> Is it unbearably hard to make the automake build to create a single
It is ;-)
> test executable without using an intermediate library? Breaking the
> test suite up into a small driver and a shared library of tests has got
> to make debugging in some IDE's more complicated than just having a
> single test executable.
I have to examine this further. I did not find a solution so far
(the issue are the global cppunit registration objects which register
the test cases with the cppunit framework). The linker usually throws
away the objects which contain those global variables, because there
are no references from the main program into the objects. Maybe there
is another solution...
> While you are playing on Solaris, have you had a chance to try the Sun
> compilers. Apparently, they are now available through opensolaris.org,
> but the site is not responding well at the moment.
I have just run the sources through the ForteV7 compiler.
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.
The latter two are caused by different parameter type qualifiers
(const/non-const) which does not seem to be a problem for gcc.
Should be easy to fix.
Regards,
Andreas
Re: log4cxx build on SUN Solaris
Posted by Chris Williams <ch...@yahoo.com>.
You can now get Sun Studio 11 from Sun for free from their website. A few months ago, I tired to compile with Sun Studio 10 and documented my findings to the mailing list. I am hoping to get back on my Sun box to help put with this task since we are looking to use log4cxx in a project soon.
Chris
----- Original Message ----
From: Andreas Fester <af...@apache.org>
To: Log4CXX User <lo...@logging.apache.org>; Log4CXX Dev <lo...@logging.apache.org>
Sent: Friday, December 16, 2005 05:49:52
Subject: Re: log4cxx build on SUN Solaris
Curt Arnold wrote:
> Is it unbearably hard to make the automake build to create a single
It is ;-)
> test executable without using an intermediate library? Breaking the
> test suite up into a small driver and a shared library of tests has got
> to make debugging in some IDE's more complicated than just having a
> single test executable.
I have to examine this further. I did not find a solution so far
(the issue are the global cppunit registration objects which register
the test cases with the cppunit framework). The linker usually throws
away the objects which contain those global variables, because there
are no references from the main program into the objects. Maybe there
is another solution...
> While you are playing on Solaris, have you had a chance to try the Sun
> compilers. Apparently, they are now available through opensolaris.org,
> but the site is not responding well at the moment.
I have just run the sources through the ForteV7 compiler.
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.
The latter two are caused by different parameter type qualifiers
(const/non-const) which does not seem to be a problem for gcc.
Should be easy to fix.
Regards,
Andreas
Re: log4cxx build on SUN Solaris
Posted by Andreas Fester <af...@apache.org>.
>> Is it unbearably hard to make the automake build to create a single
>> test executable without using an intermediate library? Breaking the
>> test suite up into a small driver and a shared library of tests has got
>> to make debugging in some IDE's more complicated than just having a
>> single test executable.
Ok, I have now adjusted the automake build for the test
suite to the ant approach. The ant build simply collects all
.cpp files below tests/src/** and directly links the object files to
one executable, without creating static archive libraries for each
sub directory. I think this is a proper approach; some hints
on cppunit also say not to use (static) libraries with cppunit,
due to similar problems.
If there are no objections, I will commit this ...
Best Regards,
Andreas
Re: log4cxx build on SUN Solaris
Posted by Andreas Fester <af...@apache.org>.
Curt Arnold wrote:
> Is it unbearably hard to make the automake build to create a single
It is ;-)
> test executable without using an intermediate library? Breaking the
> test suite up into a small driver and a shared library of tests has got
> to make debugging in some IDE's more complicated than just having a
> single test executable.
I have to examine this further. I did not find a solution so far
(the issue are the global cppunit registration objects which register
the test cases with the cppunit framework). The linker usually throws
away the objects which contain those global variables, because there
are no references from the main program into the objects. Maybe there
is another solution...
> While you are playing on Solaris, have you had a chance to try the Sun
> compilers. Apparently, they are now available through opensolaris.org,
> but the site is not responding well at the moment.
I have just run the sources through the ForteV7 compiler.
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.
The latter two are caused by different parameter type qualifiers
(const/non-const) which does not seem to be a problem for gcc.
Should be easy to fix.
Regards,
Andreas
Re: log4cxx build on SUN Solaris
Posted by Andreas Fester <af...@apache.org>.
Curt Arnold wrote:
> Is it unbearably hard to make the automake build to create a single
It is ;-)
> test executable without using an intermediate library? Breaking the
> test suite up into a small driver and a shared library of tests has got
> to make debugging in some IDE's more complicated than just having a
> single test executable.
I have to examine this further. I did not find a solution so far
(the issue are the global cppunit registration objects which register
the test cases with the cppunit framework). The linker usually throws
away the objects which contain those global variables, because there
are no references from the main program into the objects. Maybe there
is another solution...
> While you are playing on Solaris, have you had a chance to try the Sun
> compilers. Apparently, they are now available through opensolaris.org,
> but the site is not responding well at the moment.
I have just run the sources through the ForteV7 compiler.
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.
The latter two are caused by different parameter type qualifiers
(const/non-const) which does not seem to be a problem for gcc.
Should be easy to fix.
Regards,
Andreas
Re: log4cxx build on SUN Solaris
Posted by Curt Arnold <ca...@apache.org>.
On Dec 15, 2005, at 7:30 AM, Andreas Fester wrote:
> Hi,
>
> the latest tarball from
> http://www.littletux.net/log4cxx/log4cxx-0.9.8.tar.gz
>
> is now compilable on Solaris (I verified it on Solaris 2.9
> with gcc 3.3). The test cases also execute properly.
>
> The main changes were to fix the detection of std::wstring
> instead of wchar_t, to wrap some pieces of code which use
> wstring with the appropriate #ifdefs and to get rid
> of the non-portable linker options when creating the test
> suite.
>
> I still have to adjust the build.xml so that the result
> is the same regarding the testsuite shared library,
> then I will commit the patches.
>
> Regards,
>
> Andreas
Is it unbearably hard to make the automake build to create a single
test executable without using an intermediate library? Breaking the
test suite up into a small driver and a shared library of tests has
got to make debugging in some IDE's more complicated than just having
a single test executable.
While you are playing on Solaris, have you had a chance to try the
Sun compilers. Apparently, they are now available through
opensolaris.org, but the site is not responding well at the moment.