Re: linking error whith 0.9.8 release

On Sep 6, 2006, at 4:50 AM, Nicolas Bastien wrote:

> Hi ,
>
> i'm trying to compile the 0.9.8 version updated by svn,  with gcc  
> version 4.1.1on sparc-sun-solaris2.8 ( with apr ,  apr-utils,  
> enable-unicode and  without cppunit)
>
> I've got a linking error  :
>
>
> ld: warning: file /app/DINB/local/lib/libstdc++.so: attempted  
> multiple inclusion of file
> Undefined                       first referenced
>  symbol                             in file
> log4cxx::helpers::UnicodeHelper::encodeWide(unsigned int,  
> wchar_t*)../src/.libs/liblog4cxx.so
> log4cxx::helpers::UnicodeHelper::decodeWide(wchar_t const*&,  
> wchar_t const*)../src/.libs/liblog4cxx.so
> log4cxx::helpers::UnicodeHelper::lengthUTF8(wchar_t)../src/.libs/ 
> liblog4cxx.so
> ld: fatal: Symbol referencing errors. No output written to .libs/ 
> simplesocketserver
> collect2: ld returned 1 exit status
> make[1]: *** [simplesocketserver] Error 1
> make: *** [all-recursive] Error 1
> ln: cannot create liblog4cxx.so.9: File exists
> ln: cannot create liblog4cxx.so: File exists
> ld: warning: file /app/DINB/local/lib/libstdc++.so: attempted  
> multiple inclusion of file
> Undefined                       first referenced
>  symbol                             in file
> log4cxx::helpers::UnicodeHelper::encodeWide(unsigned int,  
> wchar_t*)../src/.libs/liblog4cxx.so
> log4cxx::helpers::UnicodeHelper::decodeWide(wchar_t const*&,  
> wchar_t const*)../src/.libs/liblog4cxx.so
> log4cxx::helpers::UnicodeHelper::lengthUTF8(wchar_t)../src/.libs/ 
> liblog4cxx.so
> ld: fatal: Symbol referencing errors. No output written to .libs/ 
> simplesocketserver
> collect2: ld returned 1 exit status
> make[1]: *** [simplesocketserver] Error 1
> make: *** [install-recursive] Error 1
These specific unresolved references are the indicator that nature of  
wchar_t on a platform could not be determined which is known to occur  
on Solaris and Mac OS/X.  On Solaris, wchar_t can be either UCS-4  
(most Solaris versions) or something else (on Traditional Chinese or  
Korean versions of Solaris).  Since the target character set is not  
known at compile time, the compiler does not set __STD_ISO_10646__  
which would indicate that wchar_t is UCS-4.  The solution is to  
either suppress wchar_t support or to specify __STD_ISO_10646__ and  
limit your distribution to Solaris versions other than Traditional  
Chinese or Korean.  I believe the enable-unicode flag in the  
autotools build is misnamed, I believe it is the equivalent of  
has.wchar_t on the Ant build and indicates whether the wchar_t  
character type is supported.  Regardless of the state of those flags,  
internal processing in log4cxx is always Unicode, but whether UTF-8  
char's or wchar_t's are used depends on the settings and platform.

Previously discussed in http://marc.theaimsgroup.com/?l=log4cxx- 
user&m=114313201623098&w=2

> Can you tell me when the 0.9.8  is going to be released .
> Thank you for your help

Any releases require a vote by the log4cxx committers and the logging  
services PMC and can't prejudge that they would approve any  
particular release candidate.  However, the hold up has been having a  
release candidate to vote on.  And guess what I've been working on.   
I've got a request into ASF infrastructure to fix some directory  
permissions so that I can place items at http://people.apache.org/ 
builds/logging and that has been holding up a log4j-1.2.14 release  
candidate and vote.  The same issue would also affect a log4cxx  
release candidate.  I'm likely to put up a RC1 that even I know has  
some unfinished edges just to get some early feedback and not expect  
a formal vote until RC2 or later.  Anyway, since this release will  
not be binary compatible with log4cxx-0.9.7, the minor version number  
must change, so I've been using 0.10.0 as the version number.