thanks for the advice. I'm going to disable the wchar_t definition.
I'm waiting to test the 0.10.0 RC1
brgs
Nicolas BASTIEN
07/09/2006 07:37
|
|
> 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.
