logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Williams <chris_d_willi...@yahoo.com>
Subject Re: log4cxx build on SUN Solaris
Date Fri, 16 Dec 2005 15:30:56 GMT
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 <afester@apache.org>
To: Log4CXX User <log4cxx-user@logging.apache.org>; Log4CXX Dev <log4cxx-dev@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





Mime
View raw message