ostream link errors with icl 11.0.074 on Windows

[Christopher_Hulbert]

I'm trying to build the subversion trunk of wxWidgets (http://www.wxwidgets.org/)on Windows using the Intel icl 11.0.074. I get the link error below. Building with MS VS 2003 .Net gives no link error. I need help figuring out what's going on. One of the wxWidgets developer seemed to indicate that it might be related to template instantiation from a DLL. The link error is below. The thread posted on comp.soft-sys.wxwindows can be read here (http://groups.google.com/group/comp.soft-sys.wxwindows/browse_thread/thread/54218b5c439487e7)

link /DLL /NOLOGO /OUT:..\..\lib\intel_dll
\wxmsw290_intel_isl_intel.dll /pdb:"..\..\lib\intel_dll
\wxmsw290_intel_isl_intel.pdb" /LIBPATH:..\..\lib\intel_dll @c:\temp
\nm82D.tmp
Creating library ..\..\lib\intel_dll\wxmsw29.lib and object ..\..
\lib\intel_dll\wxmsw29.exp
monodll_string.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) class std::basic_ostreamstd::char_traits > & __cdecl std::operator<<(class
std::basic_ostream > &,char const
*)" (__imp_??6std@@YAAAV?$basic_ostream@DU?
$char_traits@D@std@@@0@AAV10@PBD@Z) referenced in function "class
std::basic_ostream > & __cdecl
operator<<(class std::basic_ostream

> &,class wxScopedCharTypeBuffer const &)" (??6@YAAAV?

$basic_ostream@DU?$char_traits@D@std@@@std@@AAV01@ABV?
$wxScopedCharTypeBuffer@D@@@Z)
monodll_variant.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) class std::basic_ostreamstd::char_traits > & __cdecl std::operator<<(class
std::basic_ostream > &,char const
*)" (__imp_??6std@@YAAAV?$basic_ostream@DU?
$char_traits@D@std@@@0@AAV10@PBD@Z)
..\..\lib\intel_dll\wxmsw290_intel_isl_intel.dll : fatal error
LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.

[JenniferJ]

This issue has been reported to compiler team. When there's any news, I'll let you all know.

It seems that you will encounter this issue when using the ICL with VC.NET 2003.

Jennifer

[Judith_W_Intel]

I think I understand what the problem is...

MSVC++ 2003 and later versions are not link compatible with
MSVC++ 2002 and earlier versions because they mangle certain
symbols differently.

The mangled name of the symbol you are seeing as unresolved,
i.e.

__imp_??6std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z

would only have been mangled this way if you either:

(1) compiled the object file in a MSVC++ 2002 environment
or
(2) used the /Qvc7 or /Qvc6 flag in your compilation.

If you do either of the above you cannot link successfully
against the MSVC++ 2003 C++ standard library.

If you had compiled correctly (either with the /Qvc7.1
switch or in a MSVC++ 2003 environment) the symbol would
have been mangled as:

__imp_??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@st
d@@@0@AAV10@PBD@Z

For the reasons above I don't think users should ever explicitly
specify the /Qvc switch. If you omit the switch the icl driver
will figure out which compatibility mode to use based upon
the version of the cl.exe executable in the user's PATH.
This is what I mean by "environment".

Please check to see if the problem is as described above.

thanks,
Judy