logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Log4cxx in my project, unresolved symbols despite hours of work
Date Thu, 29 Nov 2007 18:10:07 GMT

On Nov 29, 2007, at 11:01 AM, Eborn, Eric D wrote:

> Thanks Curt
> Your advice has gotten me closer to a solution, I changed the projects
> calling convention to __cdecl and it builds, which would seem to
> indicate that you hunch was correct, I did build log4cxx with that  
> same
> convention (though I never specified such, is it a default with ant
> perhaps? Or the compiler itself?)

__cdecl is the "C" calling convention and is the default for VC  
projects and for cl, __stdcall was formerly known as the "Pascal"  
calling convention but is the convention that is used to call any  
Win32 API methods which are explictly declared as __stdcall.

> The std::vector<_ty> errors that I mentioned were showing up in my
> project when I tried to link the shared libs when I didn't include the
> STATIC directive.  This occurred for unknown reasons which I didn't
> pursue because I didn't require shared libs.

Sounds like that was backwards, LOG4CXX_STATIC should not be used with  
shared libraries, it should be used with static libraries.

> So my filter builds now but I get a strange error when I put any  
> call in
> the code to log a string (i.e. LOG4CXX_DEBUG(logger, "Debug  
> Test."); ).
> The error is as follows:
> The instruction at "0x010cecbc" reference memeory at "0x00000034".   
> The
> memory could not be "read".  [ok][cancel]
> This error goes away and the filter functions as before when I include
> the header and even create an instance of the logger variable with:
> LoggerPtr logger(Logger::getLogger("MyApp"));

Sorry, I can't make any diagnosis off that description.

> I think I would like to rebuilt log4cxx using the same calling
> convention as my filter instead of rebuilding my filter with a  
> differenc
> calling convention, even though I know not what consequences if any  
> this
> has.
> Please advise.

Sorry, we haven't made any tests using the non-default calling  
conventions.  Remember, you would need to build the whole stack (apr,  
apr-util and log4cxx consistently, any other third-party code base)  
with consistent conventions.  Don't know any reason for log4cxx, apr  
or apr-util not to work with any consistent calling convention, just  
haven't tested it.

View raw message