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 Vic Simkus <vi...@gmail.com> on 2007/11/26 07:38:04 UTC
NTEventLogAppender constructor linking problem
Hello
I'm using the latest version of log4cxx (sucked down svn HEAD
yesterday). I'm having a weird problem linking against it. The
constructor for NTEventLogAppender is not being found (error bellow).
The DLL does export it, I've verified it using the "dependency walker"
(signature bellow). If I call default constructor it links fine.
Everything else seems to be working OK otherwise for the most part -
i.e. I'm able to link the application and get logging output. I think
this has to do something with char/w_char/short stuffs, but not quite
sure how to solve it. This one has me completely stumped. Any
suggestions?
Oh, this is all under VC2003 with SP1.
Thanks
Vic
log4cxx::nt::NTEventLogAppender::NTEventLogAppender(class
std::basic_string<unsigned short,struct std::char_traits<unsigned
short>,class std::allocator<unsigned short> > const &,class
std::basic_string<unsigned short,struct std::char_traits<unsigned
short>,class std::allocator<unsigned short> > const &,class
std::basic_string<unsigned short,struct std::char_traits<unsigned
short>,class std::allocator<unsigned short> > const &,class
nt::helpers::ObjectPtrT<class log4cxx::Layout> const &)
Error:
main.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: __thiscall
log4cxx::nt::NTEventLogAppender::NTEventLogAppender(class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > const ,class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > const &,class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > const &,class
log4cxx::helpers::ObjectPtrT<class log4cxx::Layout> const &)"
(__imp_??0NTEventLogAppender@nt@log4cxx@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@00ABV?$ObjectPtrT@VLayout@log4cxx@@@helpers@2@@Z)
referenced in function _main
Re: NTEventLogAppender constructor linking problem
Posted by Vic Simkus <vi...@gmail.com>.
On Nov 26, 2007 11:47 AM, Curt Arnold <ca...@apache.org> wrote:
>
>
> On Nov 26, 2007, at 12:38 AM, Vic Simkus wrote:
>
> > Hello
> >
> > I'm using the latest version of log4cxx (sucked down svn HEAD
> > yesterday). I'm having a weird problem linking against it. The
> > constructor for NTEventLogAppender is not being found (error bellow).
> > The DLL does export it, I've verified it using the "dependency walker"
> > (signature bellow). If I call default constructor it links fine.
> > Everything else seems to be working OK otherwise for the most part -
> > i.e. I'm able to link the application and get logging output. I think
> > this has to do something with char/w_char/short stuffs, but not quite
> > sure how to solve it. This one has me completely stumped. Any
> > suggestions?
> >
> > Oh, this is all under VC2003 with SP1.
> >
> > Thanks
> > Vic
> >
> >
> > log4cxx::nt::NTEventLogAppender::NTEventLogAppender(class
> > std::basic_string<unsigned short,struct std::char_traits<unsigned
> > short>,class std::allocator<unsigned short> > const &,class
> > std::basic_string<unsigned short,struct std::char_traits<unsigned
> > short>,class std::allocator<unsigned short> > const &,class
> > std::basic_string<unsigned short,struct std::char_traits<unsigned
> > short>,class std::allocator<unsigned short> > const &,class
> > nt::helpers::ObjectPtrT<class log4cxx::Layout> const &)
> >
> >
> > Error:
> >
> > main.obj : error LNK2019: unresolved external symbol
> > "__declspec(dllimport) public: __thiscall
> > log4cxx::nt::NTEventLogAppender::NTEventLogAppender(class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> > const ,class std::basic_string<char,struct
> > std::char_traits<char>,class std::allocator<char> > const &,class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> > const &,class
> > log4cxx::helpers::ObjectPtrT<class log4cxx::Layout> const &)"
> > (__imp_??0NTEventLogAppender@nt@log4cxx@@QAE@ABV?$basic_string@DU?
> > $char_traits@D@std@@V?$allocator@D@2@@std@@00ABV?
> > $ObjectPtrT@VLayout@log4cxx@@@helpers@2@@Z)
> > referenced in function _main
>
>
> The log4cxx.dll entry is consistent with a normal Windows build where
> LogString == std::basic_string<wchar_t>. That is, log4cxx uses
> wchar_t (which is UTF-16 on Windows) as the internal string
> representation and all logging requests are converted as necessary to
> UTF-16.
>
> The linking error appears to expect that LogString ==
> std::basic_string<char> which is the normal Linux default where the
> char values are UTF-8 and all logging requests are converted as
> necessary to UTF-8.
>
> This type of linking error would occur if somehow your app was
> compiled with a log4cxx/log4cxx.h that was not consistent with the
> DLL's version. For the Microsoft compilers, you would expect that
> log4cxx/log4cxx.h would just be a copy of log4cxx/log4cxx.hw.
>
> Perhaps running a cygwin or MinGW build on the same checked out copy
> of source could result in a mismatched log4cxx.h file.
>
Hello
I deleted the source, checked out the whole tree again and recompiled
everything. It links. Hurray! I must have fat-fingered a header
file somewhere along the line. Now if only the log events would show
up in event log....
Re: NTEventLogAppender constructor linking problem
Posted by Curt Arnold <ca...@apache.org>.
On Nov 26, 2007, at 12:38 AM, Vic Simkus wrote:
> Hello
>
> I'm using the latest version of log4cxx (sucked down svn HEAD
> yesterday). I'm having a weird problem linking against it. The
> constructor for NTEventLogAppender is not being found (error bellow).
> The DLL does export it, I've verified it using the "dependency walker"
> (signature bellow). If I call default constructor it links fine.
> Everything else seems to be working OK otherwise for the most part -
> i.e. I'm able to link the application and get logging output. I think
> this has to do something with char/w_char/short stuffs, but not quite
> sure how to solve it. This one has me completely stumped. Any
> suggestions?
>
> Oh, this is all under VC2003 with SP1.
>
> Thanks
> Vic
>
>
> log4cxx::nt::NTEventLogAppender::NTEventLogAppender(class
> std::basic_string<unsigned short,struct std::char_traits<unsigned
> short>,class std::allocator<unsigned short> > const &,class
> std::basic_string<unsigned short,struct std::char_traits<unsigned
> short>,class std::allocator<unsigned short> > const &,class
> std::basic_string<unsigned short,struct std::char_traits<unsigned
> short>,class std::allocator<unsigned short> > const &,class
> nt::helpers::ObjectPtrT<class log4cxx::Layout> const &)
>
>
> Error:
>
> main.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) public: __thiscall
> log4cxx::nt::NTEventLogAppender::NTEventLogAppender(class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > const ,class std::basic_string<char,struct
> std::char_traits<char>,class std::allocator<char> > const &,class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > const &,class
> log4cxx::helpers::ObjectPtrT<class log4cxx::Layout> const &)"
> (__imp_??0NTEventLogAppender@nt@log4cxx@@QAE@ABV?$basic_string@DU?
> $char_traits@D@std@@V?$allocator@D@2@@std@@00ABV?
> $ObjectPtrT@VLayout@log4cxx@@@helpers@2@@Z)
> referenced in function _main
The log4cxx.dll entry is consistent with a normal Windows build where
LogString == std::basic_string<wchar_t>. That is, log4cxx uses
wchar_t (which is UTF-16 on Windows) as the internal string
representation and all logging requests are converted as necessary to
UTF-16.
The linking error appears to expect that LogString ==
std::basic_string<char> which is the normal Linux default where the
char values are UTF-8 and all logging requests are converted as
necessary to UTF-8.
This type of linking error would occur if somehow your app was
compiled with a log4cxx/log4cxx.h that was not consistent with the
DLL's version. For the Microsoft compilers, you would expect that
log4cxx/log4cxx.h would just be a copy of log4cxx/log4cxx.hw.
Perhaps running a cygwin or MinGW build on the same checked out copy
of source could result in a mismatched log4cxx.h file.