VS 2015 RC linker std::codecvt error

Question

Hi,

I'm geting an STL-related link error, using Microsoft Visual Studio Community 2015 RC (Version 14.0.22823.1 D14REL)

I'm linking a C++ DLL and successfully using many functions from the STL, but it can't find stuff related to std::codecvt:

             error LNK2001: unresolved external symbol "__declspec(dllimport) public: static class std::locale::id std::codecvt<char32_t,char,struct _Mbstatet>::id" (__imp_?id@?$codecvt@_UDU_Mbstatet@@@std@@2V0locale@2@A)

The source code reference causing this issue:

std::wstring_convert< std::codecvt_utf8<char32_t>, char32_t > convert;

My code generation is for multithread dll,  and I have verified through verbose linking that MSVCPRT.lib is being searched  at link time.

Any ideas ?

Answer 1

Yes, this is a known issue. It is not yet fixed, and may not be fixed before RTM. However, you should be able to use unsigned int or __int32 instead of char32_t to get the correct results.

Scot

---

Developer Support Engineer

Answer 2

Thanks for the reply Scot, it's helpful to know :)

Answer 3

I logged this on connect a few weeks ago: https://connect.microsoft.com/VisualStudio/feedback/details/1348277/link-error-when-using-std-codecvt-utf8-utf16-char16-t

Answer 4

Thanks!

By the way what's the practical diff between these two sites ? Is one the 'official' support or community for all things Visual*? 

https://connect.microsoft.com/VisualStudio

 

https://social.msdn.microsoft.com/Forums/en-US/user/forums (visual c++ forum, etc.)

 

Answer 5

The "Connect" site is for communicating directly to the product group for VS.  The responses there may be limited to things like

"Tell us how to reproduce it, because we haven't been able to do so yet", and
"Yes, thanks for telling us, we'll fix it in a future version" and
"This is by design, sorry.  But here's a workaround", etc.
Connect is very useful in helping to make sure our PG knows about problems.  You can also find existing reports and increase the "me too" count so they know which issues are impacting the most people.

The "Social" site, on the other hand, is primarily so that people sharing a common interest in a product can ask questions and give each other answers or share experiences.  From time to time, you will also see Microsoft employees like myself monitoring and replying to threads, but often the answers will come from other users who aren't MSFT.

Scot

---

Developer Support Engineer

Answer 6

Visual Studio is Version 14.0.24720.00 Update 1 now, and this bug is still there!

I have this code which produce the same error:

std::wstring_convert<std::codecvt_utf8_utf16<char16_t>, char16_t> utf16_conv;
std::u16string utf16_string = utf16_conv.from_bytes(utf8_string);

Is there a workaround for UTF-16 conversion? I assume char16_t is broken as is with char32_t?

Answer 7

Use wchar_t or unsigned short instead of char16_t, and it should work.

This is an active bug in our database (VSO#143857), which we'll investigate for a future release, but we're currently working on higher priority things.

Answer 8

Two years later, the bug still exists in VS2017 (latest version checked: 15.6.0).

The following code does not link:

std::locale loc;
auto const& cvt = std::use_facet<std::codecvt<char32_t, char, std::mbstate_t>>(loc);

Please fix it.

Answer 9

I think it is fairly unlikely that this will be fixed before the next major VC version. Don't forget that the compiler only had a binary compatible minor version bump with the release of VS2017, the current version (VS2017 15.5.5) being v14.12 and the latest preview release being v14.13. If there was a change now, it could end up with binary incompatible changes between different versions of the VC2017 runtime.

---

This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

Answer 10

I believe it is a library issue, not a compiler one.

Answer 11

It is a library issue, but Microsoft always tries to keep binary compatibility within a version of Visual Studio. So if you install the VS2017 RTM runtime and run a program built with VS2017 15.5, then it will run.

The fix that you want will introduce some new exports in one of the runtime libraries, probably msvcp140.dll. This would mean that it would be possible to get into a situation where you would need to update the VC redistributable on a system because when you start an application built with the newest version of Visual Studio, it will fail to run because an entrypoint was not found in the runtime. This is how it could be binary incompatible.

---

This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

Answer 12

And this is a good reason to not fix a bug that makes valid code fail to build for two an a half years?

Answer 13

I guess if you are asking this then you either don't care about binary compatibility or don't understand the origins of terms like DLL hell. The policy for numbered versions of the VC runtime having a stable ABI came from somewhere.

Sometimes not potentially breaking your current user base is a higher priority than just fixing a long standing bug.

---

This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

Answer 14

Yes.  Darran's answer fits with the plan of the Visual C++ libraries team.  You may have observed that the runtime libraries that released with VS 2017 have the same names as those we released with VS 2015.  There was a very deliberate intention of maintaining binary compatibility.  If we released a fix to resolve a bug, but that breaks binary compatibility, we would hurt far more of our customers than we would help.  Any programs built with VC++ 2015 or 2017 would be vulnerable to such a change.

Thus, a fix to let your code compile would require releasing a newly-named library that would not conflict with the existing names with "140" in them.  This is a possibility, but not likely to be in VS 2017.

---

Developer Support Engineer

Answer 15

Adding an export should not affect the programs originally compiled with the previous (buggy) DLL.

I agree that it would make new programs that depend on the feature being fixed fail when linked with the old (buggy) DLL.

However, you cannot decide to not fix that bug and at the same time claim that your C++11/C++14 standard library implementation is fully conformant.

If you are not planning on fixing it, you should at the very least document it in the online help, and preferably provide workaround examples for common usage scenarios.

Not doing that is disingenuous.