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 Wed, 28 Nov 2007 22:31:11 GMT

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