linking error whith 0.9.8 release

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.

Re: linking error whith 0.9.8 release

MSVC2005 question

I can't get my log4cxx based code to compile when I add the log4cxx/include folder to my project settings /
additional includes.  If I add the log4cxx\include folder as a global include value for the IDE
("Tools/Options/Projects & Solutions/VS Dirs/Include") it works fine.   Is there any particular reason
log4cxx defines all their includes using <header.h> notation instead of "header.h"?

Thanks

-----Original Message-----
From: log4cxx-user-digest-help <at> logging.apache.org
[mailto:log4cxx-user-digest-help <at> logging.apache.org] 
Sent: Wednesday, September 06, 2006 4:51 AM
To: log4cxx-user <at> logging.apache.org
Subject: log4cxx-user Digest 6 Sep 2006 09:51:13 -0000 Issue 260

log4cxx-user Digest 6 Sep 2006 09:51:13 -0000 Issue 260

Topics (messages 1682 through 1685):

Re: How create 1 log file for a day?
	1682 by: Borut Hadžialić
	1684 by: val

Unable to add appender to AsyncAppender
	1683 by: Adams Christian

linking error whith 0.9.8 release
	1685 by: Nicolas Bastien

Administrivia:

To subscribe to the digest, e-mail:
	log4cxx-user-digest-subscribe <at> logging.apache.org

To unsubscribe from the digest, e-mail:
	log4cxx-user-digest-unsubscribe <at> logging.apache.org

To post to the list, e-mail:
	log4cxx-user <at> logging.apache.org

----------------------------------------------------------------------

MSVC2005 Link Error in 0.9.8

My log4cxx code compiles fine but fails to link with the following
error:

Error	1	error LNK2019: unresolved external symbol
"__declspec(dllimport) public: static class
log4cxx::helpers::ObjectPtrT<class log4cxx::Logger> __cdecl
log4cxx::Logger::getLogger(char const * const)"
(__imp_?getLogger <at> Logger <at> log4cxx <at>  <at> SA?AV?$ObjectPtrT <at> VLogger <at> log4cxx <at>  <at>  <at> he
lpers <at> 2 <at> QBD <at> Z) referenced in function "void __cdecl `dynamic initializer
for 'logger''(void)" (??__Elogger <at>  <at> YAXXZ)	ExchangePumpGUI.obj	

I have unsuccessfully tried linking against:

log4cxx\build\release\shared\log4cxx.lib

and

log4cxx\build\debug\shared\log4cxxd.lib

Anyone else had linking problems in MSVC2005?

Thanks!

Dll-interface warnings

Hi,

Because version 0.9.7 of log4cxx isn't recommended, I'm building the CVS
Head following the instructions that came with the source. Building the
libs runs smooths (VS2003), but when I use the libs in my project, I get
a lot of dll-interface warnings when compiling. I didn't get these with
version 0.9.7 so I guess I'm overlooking something? I searched the
mailing list archives but found close to nothing on this subject.

Can somebody help me out or should I just ignore the warnings?

Thanks in advance,
Merijn

Thread safety problem

Hello,
I m using QThread and Log4cxx in a project. I created a simple class 
with static member to access logging anywhere in my soft.
But when I m accessing from another thread I have some kind of random crash.
I tested without multithread and it work fine.
It s written in Log4cxx Faq that it s Thread safe. Am I wrong to use 
class static members or is there a bug in the thread safe 
functionnality? Is it problem to use QT Qthread with log4cxx?

Thank you for any kind help.
Best regards.

here the class declaration, initialization, and log sample.

//my class
class Log{
public :   
    static log4cxx::logstream stream;
    static log4cxx::LoggerPtr logger;
};

//initialization
log4cxx::LoggerPtr Log::logger(log4cxx::Logger::getLogger("Logger"));
log4cxx::logstream Log::stream(Log::logger, log4cxx::Level::DEBUG);

//logging sample
Log::stream<<"message"<<LOG4CXX_ENDMSG;

RE: Dll-interface warnings

> -----Oorspronkelijk bericht-----
> Van: Merijn Vandenabeele [mailto:merijn <at> tnisoft.com] 
> Verzonden: donderdag 14 september 2006 10:45
> Aan: log4cxx-user <at> logging.apache.org
> Onderwerp: Dll-interface warnings
> 
> Hi,
> 
> Because version 0.9.7 of log4cxx isn't recommended, I'm 
> building the CVS Head following the instructions that came 
> with the source. Building the libs runs smooths (VS2003), but 
> when I use the libs in my project, I get a lot of 
> dll-interface warnings when compiling. I didn't get these 
> with version 0.9.7 so I guess I'm overlooking something? I 
> searched the mailing list archives but found close to nothing 
> on this subject.
> 
> Can somebody help me out or should I just ignore the warnings?
> 
> Thanks in advance,
> Merijn
> 

Digging into the source, I guess config_msvc.h.in has something to do
with these warnings.

#if defined(WIN32) || defined(_WIN32)
#pragma warning(disable : 4250 4251 4786 4290)
#endif

However, it's not clear to me what I should do with this file. I found
no references to it in any other log4cxx files.

Any hints?

Thanks in advance,
Merijn

ApacheCON US 2006

ApacheCON US 2006 (http://www.apachecon.com) will be held on October  
9-13 in Austin, TX.  Registration prices increase yet again tomorrow  
and hotel reservations should be made soon to take advantage of the  
special conference room rates.  I've tentatively scheduled a Logging  
Services BOF for Thursday night (http://wiki.apache.org/apachecon/ 
BirdsOfaFeatherUs06) and plan to be at the Hackathon on Monday and  
Tuesday.

If you have specific topics that you'd like to discuss at ApacheCON  
or other suggestions, please post them on  
general <at> logging.apache.org.  Hope to see some of you there. 

Pattern converters (or FileAppender) not thread safe?

I'm currently using several loggers in an multi-threaded application. I
overloaded the Logger class and some of it's methods, but not callAppenders, and
i'm using and extended FileAppender and a simple ConsoleAppender. 
I keep getting an Access Violation Exception in DatePatternConverter. 
When it happens i have 2 FileAppenders (for different loggers and files) in the
same Converter.

My SLogger::forcedLog just tests some more conditions than the original
forcedLog and my SFileAppender::subAppend just removes some forbidden chars from
the log message:
void SFileAppender::subAppend(const LoggingEventPtr& event, Pool& p)
{
LogString theMessage = event->getMessage();
for (LogString::iterator it = theMessage.begin(); it != theMessage.end(); it++)
{
	if (forbiddenChars.find((*it))!=LogString::npos) (*it) = ' ';
}
FileAppender::subAppend(new SpotsLoggingEvent(event->getLogger(),
	event->getLevel(), theMessage, event->getLocationInformation()),p);
}

Oh, and i'm using STL_port
From the stack:
Thread1:
LOG4CXX! log4cxx::helpers::Transcoder::encode(class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > const &,class _STL::basic_string<unsigned short,class
_STL::char_traits<unsigned short>,class _STL::allocator<unsigned short> > &) +
257 bytes
LOG4CXX! log4cxx::helpers::StringHelper::toString(int,class
log4cxx::helpers::Pool &,class _STL::basic_string<unsigned short,class
_STL::char_traits<unsigned short>,class _STL::allocator<unsigned short> > &) +
133 bytes
LOG4CXX! NumericToken::format(class _STL::basic_string<unsigned short,class
_STL::char_traits<unsigned short>,class _STL::allocator<unsigned short> >
&,struct apr_time_exp_t const &,class log4cxx::helpers::Pool &) + 90 bytes
LOG4CXX! log4cxx::helpers::SimpleDateFormat::format(class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > &,__int64,class log4cxx::helpers::Pool &) + 202 bytes
LOG4CXX! log4cxx::pattern::CachedDateFormat::format(class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > &,__int64,class log4cxx::helpers::Pool &) + 450 bytes
LOG4CXX! log4cxx::pattern::DatePatternConverter::format(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > &,class log4cxx::helpers::Pool &) + 75 bytes
LOG4CXX! log4cxx::PatternLayout::format(class _STL::basic_string<char,class
_STL::char_traits<char>,class _STL::allocator<char> > &,class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 151 bytes
LOG4CXX! log4cxx::WriterAppender::subAppend(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 117 bytes
log4cxx::SFileAppender::subAppend(const
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent> & {...},
log4cxx::helpers::Pool & {...}) line 202 + 202 bytes
LOG4CXX! log4cxx::WriterAppender::append(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 67 bytes
LOG4CXX! log4cxx::AppenderSkeleton::doAppend(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 638 bytes
LOG4CXX! log4cxx::helpers::AppenderAttachableImpl::appendLoopOnAppenders(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 104 bytes
LOG4CXX! log4cxx::Logger::callAppenders(const
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent> & {...},
log4cxx::helpers::Pool & {...}) line 99 + 27 bytes
log4cxx::SLogger::forcedLog(const log4cxx::helpers::ObjectPtrT<log4cxx::Level> &
{...}, const
_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & {...},
const int 500106, const log4cxx::spi::LocationInfo & {...}, unsigned char 1)
line 153 + 32 bytes

Thread2:
STLPORT_VC6_UNICODE.4.5! 01003660()
LOG4CXX! log4cxx::helpers::StringHelper::toString(int,class
log4cxx::helpers::Pool &,class _STL::basic_string<unsigned short,class
_STL::char_traits<unsigned short>,class _STL::allocator<unsigned short> > &) +
133 bytes
LOG4CXX! NumericToken::format(class _STL::basic_string<unsigned short,class
_STL::char_traits<unsigned short>,class _STL::allocator<unsigned short> >
&,struct apr_time_exp_t const &,class log4cxx::helpers::Pool &) + 90 bytes
LOG4CXX! log4cxx::helpers::SimpleDateFormat::format(class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > &,__int64,class log4cxx::helpers::Pool &) + 202 bytes
LOG4CXX! log4cxx::pattern::CachedDateFormat::format(class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > &,__int64,class log4cxx::helpers::Pool &) + 450 bytes
LOG4CXX! log4cxx::pattern::DatePatternConverter::format(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > &,class log4cxx::helpers::Pool &) + 75 bytes
LOG4CXX! log4cxx::PatternLayout::format(class _STL::basic_string<char,class
_STL::char_traits<char>,class _STL::allocator<char> > &,class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 151 bytes
LOG4CXX! log4cxx::WriterAppender::subAppend(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 117 bytes
log4cxx::SFileAppender::subAppend(const
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent> & {...},
log4cxx::helpers::Pool & {...}) line 202 + 202 bytes
LOG4CXX! log4cxx::WriterAppender::append(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 67 bytes
LOG4CXX! log4cxx::AppenderSkeleton::doAppend(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 638 bytes
LOG4CXX! log4cxx::helpers::AppenderAttachableImpl::appendLoopOnAppenders(class
log4cxx::helpers::ObjectPtrT<class log4cxx::spi::LoggingEvent> const &,class
log4cxx::helpers::Pool &) + 104 bytes
LOG4CXX! log4cxx::Logger::callAppenders(const
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent> & {...},
log4cxx::helpers::Pool & {...}) line 99 + 27 bytes

Any ideas? I see no problem with 2 different FileAppenders in 2 different
Loggers running simultaneously, but if there's only one Converter...