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.
|
