Linker error (Intel Compiler 13.1.2.190)

Linker error (Intel Compiler 13.1.2.190)

I failed to build my project (under Windows 7 x64, VS2012 Update 2) that uses a rarely used /Zc:wchar_t- flag.

I have created a sample to reproduce this issue:

#include <iostream>
int main(int, char* [])
{
  std::cout << 5;
  return 0;
}

If I build it with the following flags I have a linkage error:

> icl /Zc:wchar_t- /O2 /MD /EHsc main.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.2.190 Build 20130514
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.
30 DAY EVALUATION LICENSE
main.cpp
icl: NOTE: The evaluation period for this product ends on 5-jul-2013 UTC.
Microsoft (R) Incremental Linker Version 11.00.60315.1
Copyright (C) Microsoft Corporation. All rights reserved.
-out:main.exe
main.obj
main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl std::_Yarn<unsigned short>::~_Yarn<unsigned short>(void)" (__imp_??1?$_Yarn@G@std@@QEAA@XZ) referenced in function "class std::numpunct<char> const& __cdecl std::use_facet<class std::numpunct<char> >(class std::locale const &)" (??$use_facet@V?$numpunct@D@std@@@std@@YAAEBV?$numpunct@D@0@AEBVlocale@0@@Z)
main.exe : fatal error LNK1120: 1 unresolved externals
>

I have found two workarounds for this problem. The first is to disable inline functions expansion (adding /Ob0 flag) and the second is to disable C++ exceptions (remove /EHsc flag).

>icl /Zc:wchar_t- /O2 /MD /EHsc /Ob0 main.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.2.190 Build 20130514
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.
30 DAY EVALUATION LICENSE
main.cpp
icl: NOTE: The evaluation period for this product ends on 5-jul-2013 UTC.
Microsoft (R) Incremental Linker Version 11.00.60315.1
Copyright (C) Microsoft Corporation. All rights reserved.
-out:main.exe
main.obj

>icl /Zc:wchar_t- /O2 /MD main.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.2.190 Build 20130514
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.
main.cpp
Microsoft (R) Incremental Linker Version 11.00.60315.1
Copyright (C) Microsoft Corporation. All rights reserved.
-out:main.exe
main.obj

11 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

Sergey, Thanks for these technical details. My question is did you try to use a _MBCS macro?

...
#define _MBCS
#include "iostream"
int main( int, char *[] )
{
std::cout << 5;
return 0;
}
...

>>...a rarely used /Zc:wchar_t- flag...

I agree with that and in all VS projects I work with the option is always on ( at the same time _UNICODE is also defined ).This is what MSDN says about that compiler option:
...
If /Zc:wchar_t- is specified, the compiler requires you to either define wchar_t or to include one of the many header files that defines it (for example, wchar.h ). Typically, wchar_t is defined as an unsigned short.
...

 did you try to use a _MBCS macro

Yes, but neither _MBCS nor _UNICODE change the build result.

>>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl std::_Yarn...

I will take a look at where it comes from. At the moment I see that VS 2005, 2008 and 2010 ( different Editions ) don't have it.

Finally found in VS 2010 in:

xlocale
xlocinfo
xutility

header files and, for example, there is a code like ( in xlocale ):
...
_Yarn[ char ] _Name; // locale name, or "*" if not known
...

Note: I replaced arrow-left and arrow-right with [ and ] characters because editor doen't display any text after left-arrow.

I see that this is some new STL feature introduced in VS 2010 and 2012 versions and I'm Not convinced that this is a problem with Intel C++ compiler because I would expect to see a declaration like:
...
_Yarn[ wchar_t ] _Name; // locale name, or "*" if not known
...
and a linker error in your Initial posts confirms it.

This is a short follow up.

Sergey,

I don't know if that problem affects some production application you're working on but since you have a workaround I would proceed with it. It would be nice if you contact Microsoft since xlocale is Not Intel's header. I hope that Intel software engineers will also look at the problem.

Thanks in advance.

but since you have a workaround I would proceed with it

Ok, as a workaround we chose to disable C++ exceptions though it is not very good solution because it needs some non-trivial code modifications.

Finally found in VS 2010 in:

xlocale
xlocinfo
xutility

I think that problem lies in xlocinfo header (VS2012) since this is the only file that instantiates _Yarn<wchar_t> (used for weekday and month names)

 It would be nice if you contact Microsoft since xlocale is Not Intel's header

The reason I created this thread on Intel's forum is that Microsoft's compiler successfully compiles this sample (and whole huge application):

> cl /Zc:wchar_t- /O2 /MD /EHsc main.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.60315.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
main.cpp
Microsoft (R) Incremental Linker Version 11.00.60315.1
Copyright (C) Microsoft Corporation. All rights reserved.
/out:main.exe
main.obj
>

So I think this problem is on compiler (not linker) side.

 I hope that Intel software engineers will also look at the problem.

I agree. It would be great if you forward this issue to Intel engineers.

Hello,

I'd like to inform you that this problem is known and has been fixed with Intel(R) Composer XE 2013 SP1 (14.0) and later.

Best regards,

Georg Zitzlsberger

Hello,

this is a correction:

Although it looked like the problem has been fixed with 14.0, the root cause might still be there. It also appears with the Microsoft Visual Studio* compiler:
https://connect.microsoft.com/VisualStudio/feedback/details/817221/yarn-wchar-t-specialization-does-not-link-if-zc-wchar-t-is-specified

Best regards,

Georg Zitzlsberger

I got email recently that the Microsoft team has finally fixed this, the issue will be fixed in the VS2015 RTM.

 

Faça login para deixar um comentário.