incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farid Zaripov" <Farid_Zari...@epam.com>
Subject RE: svn commit: r577000 - in /incubator/stdcxx/trunk: include/loc/_messages.h src/messages.cpp
Date Tue, 18 Sep 2007 19:38:24 GMT
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> 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
> 
> faridz@apache.org 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 &)"
(?__rw_cat_open@__rw@@YAHABV?$basic_string@DU?$char_traits@D@std@@V?$all
ocator@D@2@@std@@ABUlocale@3@@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 "
(?do_open@?$messages@D@std@@MBEHABV?$basic_string@DU?$char_traits@D@std@
@V?$allocator@D@2@@2@ABUlocale@2@@Z)
22.locale.stdcxx-554.obj : error LNK2019: unresolved external symbol
"void __cdecl __rw::__rw_cat_close(int)" (?__rw_cat_close@__rw@@YAXH@Z)
referenced in function "protected: virtual void __thiscall
std::messages<char>::do_close(int)const "
(?do_close@?$messages@D@std@@MBEXH@Z)
$(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.

Mime
View raw message