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.
