You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by "Eborn, Eric D" <er...@lmco.com> on 2007/11/27 22:07:23 UTC

Log4cxx in my project, unresolved symbols despite hours of work

I’m using MSVC 2008 Express Edition.  I downloaded the SVN head today and built it fine (after some wrestling with it), and was able to use log4cxx in one project without much problem, however, I then ported some of the code I had over into another MSVC project and again tried to integrate log4cxx and am getting a couple of errors that are stumping me:

Linking...
   Creating library .\Release/Camera.lib and object .\Release/ Camera.exp
Camera.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)
Camera.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)
..\Bin\Camera.ax : fatal error LNK1120: 2 unresolved externals

I built the log4cxx.lib both statically and dynamically and the above output is when I use the shared lib, I’ve also added the Pre-processor directive LOG4CXX_STATIC.

I’ve done everything I can think of to get this right and this mailing list is my last resort ☺  I’d hate to waste your time.



 
 
Eric Eborn, 
Software Engineer
801-545-5449
eric.d.eborn@lmco.com
 


RE: Log4cxx in my project, unresolved symbols despite hours of work

Posted by "Eborn, Eric D" <er...@lmco.com>.
One thing I noticed also is that each of the errors (with static libs) is associated with the following lines of code within my code:


LoggerPtr logger(Logger::getLogger("MyApp"));
LOG4CXX_INFO(logger, "Entering application.");

These lines were pulled out directly from the working app however, I'm terribly confused. :(

 
 
Eric Eborn, 
Software Engineer
801-545-5449
eric.d.eborn@lmco.com
 

> -----Original Message-----
> From: Eborn, Eric D
> Sent: Wednesday, November 28, 2007 7:37 AM
> To: Log4CXX User
> Subject: RE: Log4cxx in my project, unresolved symbols despite hours of
> work
> 
> 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@@@help
> ers@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
> 
> 
> > -----Original Message-----
> > From: Curt Arnold [mailto:carnold@apache.org]
> > Sent: Tuesday, November 27, 2007 2:28 PM
> > To: Log4CXX User
> > Subject: Re: Log4cxx in my project, unresolved symbols despite hours of
> > work
> >
> >
> > On Nov 27, 2007, at 3:07 PM, Eborn, Eric D wrote:
> >
> > > I’m using MSVC 2008 Express Edition.  I downloaded the SVN head
> > > today and built it fine (after some wrestling with it), and was able
> > > to use log4cxx in one project without much problem, however, I then
> > > ported some of the code I had over into another MSVC project and
> > > again tried to integrate log4cxx and am getting a couple of errors
> > > that are stumping me:
> > >
> > > Linking...
> > >    Creating library .\Release/Camera.lib and object .\Release/
> > > Camera.exp
> > > Camera.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)
> > > Camera.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)
> > > ..\Bin\Camera.ax : fatal error LNK1120: 2 unresolved externals
> > >
> > > I built the log4cxx.lib both statically and dynamically and the
> > > above output is when I use the shared lib, I’ve also added the Pre-
> > > processor directive LOG4CXX_STATIC.
> > >
> > > I’ve done everything I can think of to get this right and this
> > > mailing list is my last resort ☺  I’d hate to waste your time.
> > >
> > >
> > >
> > >
> > >
> > > Eric Eborn,
> > > Software Engineer
> > > 801-545-5449
> > > eric.d.eborn@lmco.com
> > >
> > >
> >
> >
> > You should only set LOG4CXX_STATIC when you are linking against a
> > static log4cxx library.  Your message suggests that you set and tried
> > to link against a shared library which I would guess would result in
> > the types of messages that you see (I'd expect a declspec(import) to
> > show up in the method signature if LOG4CXX_STATIC was not set).  Could
> > you confirm that your LOG4CXX_STATIC setting is consistent with the
> > type of log4cxx library that you are linking against?


Re: Log4cxx in my project, unresolved symbols despite hours of work

Posted by Curt Arnold <ca...@apache.org>.
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.

RE: Log4cxx in my project, unresolved symbols despite hours of work

Posted by "Eborn, Eric D" <er...@lmco.com>.
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.

Re: Log4cxx in my project, unresolved symbols despite hours of work

Posted by Curt Arnold <ca...@apache.org>.
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.

RE: Log4cxx in my project, unresolved symbols despite hours of work

Posted by "Eborn, Eric D" <er...@lmco.com>.
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
 

> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Tuesday, November 27, 2007 2:28 PM
> To: Log4CXX User
> Subject: Re: Log4cxx in my project, unresolved symbols despite hours of
> work
> 
> 
> On Nov 27, 2007, at 3:07 PM, Eborn, Eric D wrote:
> 
> > I’m using MSVC 2008 Express Edition.  I downloaded the SVN head
> > today and built it fine (after some wrestling with it), and was able
> > to use log4cxx in one project without much problem, however, I then
> > ported some of the code I had over into another MSVC project and
> > again tried to integrate log4cxx and am getting a couple of errors
> > that are stumping me:
> >
> > Linking...
> >    Creating library .\Release/Camera.lib and object .\Release/
> > Camera.exp
> > Camera.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)
> > Camera.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)
> > ..\Bin\Camera.ax : fatal error LNK1120: 2 unresolved externals
> >
> > I built the log4cxx.lib both statically and dynamically and the
> > above output is when I use the shared lib, I’ve also added the Pre-
> > processor directive LOG4CXX_STATIC.
> >
> > I’ve done everything I can think of to get this right and this
> > mailing list is my last resort ☺  I’d hate to waste your time.
> >
> >
> >
> >
> >
> > Eric Eborn,
> > Software Engineer
> > 801-545-5449
> > eric.d.eborn@lmco.com
> >
> >
> 
> 
> You should only set LOG4CXX_STATIC when you are linking against a
> static log4cxx library.  Your message suggests that you set and tried
> to link against a shared library which I would guess would result in
> the types of messages that you see (I'd expect a declspec(import) to
> show up in the method signature if LOG4CXX_STATIC was not set).  Could
> you confirm that your LOG4CXX_STATIC setting is consistent with the
> type of log4cxx library that you are linking against?


Re: Log4cxx in my project, unresolved symbols despite hours of work

Posted by Curt Arnold <ca...@apache.org>.
On Nov 27, 2007, at 3:07 PM, Eborn, Eric D wrote:

> I’m using MSVC 2008 Express Edition.  I downloaded the SVN head  
> today and built it fine (after some wrestling with it), and was able  
> to use log4cxx in one project without much problem, however, I then  
> ported some of the code I had over into another MSVC project and  
> again tried to integrate log4cxx and am getting a couple of errors  
> that are stumping me:
>
> Linking...
>    Creating library .\Release/Camera.lib and object .\Release/  
> Camera.exp
> Camera.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)
> Camera.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)
> ..\Bin\Camera.ax : fatal error LNK1120: 2 unresolved externals
>
> I built the log4cxx.lib both statically and dynamically and the  
> above output is when I use the shared lib, I’ve also added the Pre- 
> processor directive LOG4CXX_STATIC.
>
> I’ve done everything I can think of to get this right and this  
> mailing list is my last resort ☺  I’d hate to waste your time.
>
>
>
>
>
> Eric Eborn,
> Software Engineer
> 801-545-5449
> eric.d.eborn@lmco.com
>
>


You should only set LOG4CXX_STATIC when you are linking against a  
static log4cxx library.  Your message suggests that you set and tried  
to link against a shared library which I would guess would result in  
the types of messages that you see (I'd expect a declspec(import) to  
show up in the method signature if LOG4CXX_STATIC was not set).  Could  
you confirm that your LOG4CXX_STATIC setting is consistent with the  
type of log4cxx library that you are linking against?