Guillaume Munch wrote: > Is that all the information that the compiler gives you? Does it not > give you the name of the file?
This is the kind of error messages you often get from templates. The compiler gives the name of the file where the error occurs, but it is a system header and not in our code. What I miss however are the 'included from...' lines. This is strange. Are we using precompiled headers with MSVC? > I tried to understand the error message with what comes up on Google and > I cannot relate it to my code. In addition, one of the first hits on > Google is about a message on this list > <https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg160635.html>, > so it is possible that the bug is elsewhere (while still fixable by > adapting my code). The first hit I get is http://stackoverflow.com/questions/11076255/stdbasic-stringstreamunsigned-char-wont-compile-with-msvc-10 which explains the problem quite well IMHO: On windows, wchar_t is 16 bit, and therefore we use a custom 32 bit type as char_type. Therefore the std::numpunct facets which are defined for char and wchar_t cannot be used, and we need to provide our own. Unfortunately MS messed up their STL, which declares std::numpunct<_Elem>::id in a template, although it is not (and cannot be) provided in the runtime dll for custom character types. Because of the awkward way how dlls work (declspec dllexport etc), this declaration pretends that the symbol, is exported by a dll (other simply declaring it would not be any problem). The message on the list is related to commit e948caf6, which is supposed to fix exactly this issue. What I do not understand it why the fix does not work for your recent changes. Maybe you forgot to include docstream.h somewhere or got the include order wrong? Georg
