logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eborn, Eric D" <eric.d.eb...@lmco.com>
Subject RE: Log4cxx in my project, unresolved symbols despite hours of work
Date Thu, 29 Nov 2007 17:01:33 GMT
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?)

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.

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"));

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.


> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Wednesday, November 28, 2007 3:31 PM
> To: Log4CXX User
> Subject: Re: Log4cxx in my project, unresolved symbols despite hours
of
> work
> 
> 
> On Nov 28, 2007, at 8:37 AM, Eborn, Eric D wrote:
> 
> > I had figured as much, that I wouldn't need to use that directive if
> > using shared libs, but it cleaned up a few errors of the following
> > form:
> >
> > class 'std::vector<_Ty>' needs to have dll-interface to be used by
> > clients of class
> >
> > However, the 3 remaining errors remain the same without that
> > preprocessor diretive:
> >
> > Generating Code...
> > Linking...
> >  Creating library .\Release/Camera.lib and object .\Release/
> > Camera.exp
> > Filters.obj : error LNK2019: unresolved external symbol
> > "__declspec(dllimport) public: static class
> > log4cxx::helpers::ObjectPtrT<class log4cxx::Level> const & __stdcall
> > log4cxx::Level::getInfo(void)" (__imp_?getInfo@Level@log4cxx@@SGABV?
> > $ObjectPtrT@VLevel@log4cxx@@@helpers@2@XZ) referenced in function
> > "int __stdcall convert(unsigned char *,int &,int &)" (?
> > convert@@YGHPAEAAH1@Z)
> > Filters.obj : error LNK2019: unresolved external symbol
> > "__declspec(dllimport) public: static class
> > log4cxx::helpers::ObjectPtrT<class log4cxx::Logger> __stdcall
> > log4cxx::Logger::getLogger(char const * const)" (__imp_?
> > getLogger@Logger@log4cxx@@SG?AV?
> > $ObjectPtrT@VLogger@log4cxx@@@helpers@2@QBD@Z) referenced in
> > function "void __cdecl `dynamic initializer for 'logger''(void)" (??
> > __Elogger@@YAXXZ)
> > ..\Bin\ Camera.ax : fatal error LNK1120: 2 unresolved externals
> >
> > One difference that comes to mind is that the first project I
> > mentioned that I used the logger flawlessly with, it's configuration
> > type is set to application (.exe), while the project that is failing
> > is a Dynamic Library (.dll) (I'm building a DirectShow filter).  I
> > can't imagine what differences there would be as far as logging is
> > concerned but maybe it will give someone more insight on my problem.
> >
> > For completeness, I've also now linked with the static lib, and
> > added the preprocessor directive and get the same two unresolved
> > symbol errors with an additional unresolved symbol error (note: I
> > also linked 3 more libs that were generated statically log4cxx.lib
> > apr-1.lib aprutil-1.lib cppunit.lib:
> >
> >
> > Filters.obj : error LNK2019: unresolved external symbol "public:
> > static class log4cxx::helpers::ObjectPtrT<class log4cxx::Level>
> > const & __stdcall log4cxx::Level::getInfo(void)" (?
> > getInfo@Level@log4cxx@@SGABV?
> > $ObjectPtrT@VLevel@log4cxx@@@helpers@2@XZ) referenced in function
> > "int __stdcall convert(unsigned char *,int &,int &)" (?
> > convert@@YGHPAEAAH1@Z)
> > Filters.obj : error LNK2019: unresolved external symbol "public:
> > static class log4cxx::helpers::ObjectPtrT<class log4cxx::Logger>
> > __stdcall log4cxx::Logger::getLogger(char const * const)" (?
> > getLogger@Logger@log4cxx@@SG?AV?
> > $ObjectPtrT@VLogger@log4cxx@@@helpers@2@QBD@Z) referenced in
> > function "void __cdecl `dynamic initializer for 'logger''(void)" (??
> > __Elogger@@YAXXZ)
> > apr-1.lib(sendrecv.obj) : error LNK2019: unresolved external symbol
> > _TransmitFile@28 referenced in function _apr_socket_sendfile@24
> >
> > Thanks for your input
> 
> First the easiest, TransmitFile is provided by mswsock.lib.  If you
> are linking against log4cxx as a static library, you also need to link
> against all of the libraries that is uses (advapi32, odbc32, ws2_32
> and mswsock).
> 
> I've noticed that your unresolved symbols all have the __stdcall
> decoration.  The log4cxx headers do not explicitly declare a calling
> convention, so they should not have the __stdcall convention unless
> the filter DLL was built with the /Gz option (same as setting the
> calling convention in Project Settings/C++/Code Generation in VC6 to
> __stdcall).  It is likely that you built the log4cxx DLL using the
> __cdecl calling convention and are trying to use it from a project
> where the default calling convention is __stdcall.  The default
> calling conventions have to be consistent.
> 
> p.s.: Could you describe the std::vector<_ty> issues that you ran into
> and how you fixed them.

Mime
View raw message