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)" ([EMAIL PROTECTED]@log4cxx@@SGABV?
[EMAIL PROTECTED]@log4cxx@@@[EMAIL PROTECTED]@XZ) referenced in function
"int __stdcall convert(unsigned char *,int &,int &)" (?
convert@@[EMAIL PROTECTED])
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_?
[EMAIL PROTECTED]@log4cxx@@SG?AV?
[EMAIL PROTECTED]@log4cxx@@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) 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)" (?
[EMAIL PROTECTED]@log4cxx@@SGABV?
[EMAIL PROTECTED]@log4cxx@@@[EMAIL PROTECTED]@XZ) referenced in function
"int __stdcall convert(unsigned char *,int &,int &)" (?
convert@@[EMAIL PROTECTED])
Filters.obj : error LNK2019: unresolved external symbol "public:
static class log4cxx::helpers::ObjectPtrT<class log4cxx::Logger>
__stdcall log4cxx::Logger::getLogger(char const * const)" (?
[EMAIL PROTECTED]@log4cxx@@SG?AV?
[EMAIL PROTECTED]@log4cxx@@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) referenced in
function "void __cdecl `dynamic initializer for 'logger''(void)" (??
__Elogger@@YAXXZ)
apr-1.lib(sendrecv.obj) : error LNK2019: unresolved external symbol
[EMAIL PROTECTED] referenced in function [EMAIL PROTECTED]
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.
