[filesystem] Linker error against std::codecvt in VS2012 RC
Hi list, I foolishly installed the Visual Studio 2012 RC yesterday night and made an overnight build of Boost. It seems like there's something awry, as I'm getting a mysterious linker error in Filesystem's path.obj [1], even in a fresh empty testbed project. I'm linking Boost statically and the CRT dynamically. If I link the CRT statically, the linker error goes away. Has anyone else installed this software and can reproduce this problem? I'm building Boost against trunk, r78785. I dread to think of the horror that I will have go through in actually reporting a bug against the runtime itself :( [1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : error LNK2001: unresolved external symbol "protected: virtual int __thiscall std::codecvt<wchar_t,char,int>::do_length(int const &,char const *,char const *,unsigned int)const " (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z) -- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote:
[1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : error LNK2001: unresolved external symbol "protected: virtual int __thiscall std::codecvt<wchar_t,char,int>::do_length(int const &,char const *,char const *,unsigned int)const " (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z)
Well, you could start by preparing a simple test program that calls std::codecvt in the same way path.obj does, to eliminate Boost as a factor. If do_length is indeed not present in the dynamic runtime, this would probably be a showstopper bug against the RC, so it will get noticed. :-)
On Fri, Jun 01, 2012 at 01:07:15PM +0300, Peter Dimov wrote:
Lars Viklund wrote:
[1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : error LNK2001: unresolved external symbol "protected: virtual int __thiscall std::codecvt<wchar_t,char,int>::do_length(int const &,char const *,char const *,unsigned int)const " (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z)
Well, you could start by preparing a simple test program that calls std::codecvt in the same way path.obj does, to eliminate Boost as a factor. If do_length is indeed not present in the dynamic runtime, this would probably be a showstopper bug against the RC, so it will get noticed. :-)
Have you've _seen_ the innards of Filesystem? Anyway, it seems like I've somehow ended up with stale files somewhere in my build tree. Touching one of the filesystem files made it rebuild properly. How on earth is one supposed to distclean a Boost tree? It doesn't seem like --clean does much at all. -- Lars Viklund | zao@acc.umu.se
[Lars Viklund]
I foolishly installed the Visual Studio 2012 RC yesterday night and made an overnight build of Boost.
[1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : error LNK2001: unresolved external symbol "protected: virtual int __thiscall std::codecvt<wchar_t,char,int>::do_length(int const &,char const *,char const *,unsigned int)const " (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z)
FYI, Marshall Clow reported DevDiv#307389 "codecvt: length() and do_length() should take modifiable stateT&", which we've fixed in VC11/VS2012. Previously (in VC10 and earlier) we took const stateT&, which didn't follow the Standard. The difference is highly significant to anyone attempting to override this virtual function. Unfortunately, I have no way of informing users automatically when they're affected by this change, so my plan is to fall back on my usual response of "because the Standard told us to" - or in this case, "because Marshall told us to". :->
I dread to think of the horror that I will have go through in actually reporting a bug against the runtime itself :(
The usual path is Microsoft Connect, but you may report STL bugs directly to me at stl@microsoft.com . (I strongly appreciate self-contained repros, unless the problem in the source code is ridiculously obvious). As a service to Boost, I will also file compiler and CRT bugs (in which case a self-contained repro is mandatory, because I'm just going to copy-and-paste it into TFS and let those teams figure it out). Stephan T. Lavavej Visual C++ Libraries Developer
On Jun 1, 2012, at 3:09 PM, Stephan T. Lavavej wrote:
[Lars Viklund]
I foolishly installed the Visual Studio 2012 RC yesterday night and made an overnight build of Boost.
[1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : error LNK2001: unresolved external symbol "protected: virtual int __thiscall std::codecvt<wchar_t,char,int>::do_length(int const &,char const *,char const *,unsigned int)const " (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z)
FYI, Marshall Clow reported DevDiv#307389 "codecvt: length() and do_length() should take modifiable stateT&", which we've fixed in VC11/VS2012. Previously (in VC10 and earlier) we took const stateT&, which didn't follow the Standard.
The difference is highly significant to anyone attempting to override this virtual function. Unfortunately, I have no way of informing users automatically when they're affected by this change, so my plan is to fall back on my usual response of "because the Standard told us to" - or in this case, "because Marshall told us to". :->
I dread to think of the horror that I will have go through in actually reporting a bug against the runtime itself :(
The usual path is Microsoft Connect, but you may report STL bugs directly to me at stl@microsoft.com . (I strongly appreciate self-contained repros, unless the problem in the source code is ridiculously obvious).
As a service to Boost, I will also file compiler and CRT bugs (in which case a self-contained repro is mandatory, because I'm just going to copy-and-paste it into TFS and let those teams figure it out).
[ Warning: Untested fix follows ] If you look at boost/detail/utf8_codecvt_facet.hpp, you'll see: #if !defined(__MSL_CPP__) && !defined(__LIBCOMO__) #define BOOST_CODECVT_DO_LENGTH_CONST const #else #define BOOST_CODECVT_DO_LENGTH_CONST #endif If you change (in your copy) to replace all five of those lines with: #define BOOST_CODECVT_DO_LENGTH_CONST then it should work with VS2012 (but not with VS2011). Please file a bug so that will remember to fix it (permanently) for the next boost release. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Fri, Jun 01, 2012 at 10:09:42PM +0000, Stephan T. Lavavej wrote:
[Lars Viklund]
I dread to think of the horror that I will have go through in actually reporting a bug against the runtime itself :(
The usual path is Microsoft Connect, but you may report STL bugs directly to me at stl@microsoft.com . (I strongly appreciate self-contained repros, unless the problem in the source code is ridiculously obvious).
Yeah, I pondered CC:ing you and using Connect once I figured out if it was a proper bug, but wanted an independent repro to rule out configuration errors, which seems to have been the root cause on my side. Most of the "dread" above was the fight against Connect itself, just to have something considered "fixed in the future some time, maybe". -- Lars Viklund | zao@acc.umu.se
participants (4)
-
Lars Viklund -
Marshall Clow -
Peter Dimov -
Stephan T. Lavavej