> -----Original Message----- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 18, 2007 10:24 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r577000 - in > /incubator/stdcxx/trunk: include/loc/_messages.h src/messages.cpp > > [EMAIL PROTECTED] wrote: > > Author: faridz > > Date: Tue Sep 18 10:56:44 2007 > > New Revision: 577000 > > I'm curious about this change... > > I thought dllexport was only necessary with symbols > (functions or objects) that could be referenced from user > code (either directly, or indirectly via our own inline > functions), and that references to our own symbols from with > the stdcxx library itself, even from other translation units, > didn't need the decoration. > > In this case, I note that __rw_cat_open() is being called > from a function that's declared inline (messages::do_open() > in the primary template), so at the first glance the change > makes sense. > But then I also note that we're explicitly instantiating the > primary template on char and wchar_t (no other > specializations are allowed), which should prevent the > do_open() member function from being implicitly instantiated > in code that uses it, and that the dllexport shouldn't be necessary. > > So, does this mean that I'm missing something or that > something isn't working quite the way it should? Could it be > that MSVC is actually inlining the virtual do_open()? (Most > other compilers don't inline virtual function so I would tend > to define it out of line to save the little bit of space and > avoid code for it from being emitted in every object file > that calls it).
Without that patch the 22.locale.stdcxx-554.cpp regression test failed to link on ICC, but succeeded on MSVC. http://people.apache.org/~sebor/stdcxx/results/win_2003-1-em64t-icl-10.0 -12D-win32-576688-log.gz.txt http://people.apache.org/~sebor/stdcxx/results/win_2003-1-em64t-icl-10.0 -12d-win32-576688-log.gz.txt http://people.apache.org/~sebor/stdcxx/results/win_2003-1-x86-icl-9.1-12 d-win32-576688-log.gz.txt 22.locale.stdcxx-554.cpp Linking... (Intel C++ Environment) xilink: executing 'link' 22.locale.stdcxx-554.obj : error LNK2019: unresolved external symbol "int __cdecl __rw::__rw_cat_open(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,struct std::locale const &)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@V?$all [EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]@@Z) referenced in function "protected: virtual int __thiscall std::messages<char>::do_open(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,struct std::locale const &)const " ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @[EMAIL PROTECTED]@2@@[EMAIL PROTECTED]@2@@Z) 22.locale.stdcxx-554.obj : error LNK2019: unresolved external symbol "void __cdecl __rw::__rw_cat_close(int)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function "protected: virtual void __thiscall std::messages<char>::do_close(int)const " ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]) $(BUILDDIR)\12d\tests\22.locale.stdcxx-554.exe : fatal error LNK1120: 2 unresolved externals I'm surprised, that ICC does that because that functions (messages<>::open() and messages<>::close()) are not invoked in that test, but ICC put them into .obj file even in optimized mode (12d). Farid.
