Issue with Visual Studio 2017 15.8.4?
Issue with Visual Studio 2017 15.8.4?
Hi,
I am experiencing a problem with Visual Studio 2017. I have a wx 3.0.4 install that worked great under VS2017 15.7. I recently installed updates to VS2017 to version 15.8.4. Now, when I attempt to build a rudimentary project, I get the message below:
1>c\wxwidgets-3.0.4\include\wx\wxcrt.h(487): error C3861: 'wxStrcoll': identifier not found
1>c\wxwidgets-3.0.4\include\wx\wxcrt.h(487): note: 'wxStrcoll': function was not declared in the template definition context and can be found only via argument-dependent lookup in the instantiation context
1>c\wxwidgets-3.0.4\include\wx\wxcrt.h(496): note: see reference to function template instantiation 'int wxStrcoll_String<const wchar_t*>(const wxString &,const T &)' being compiled
1> with
1> [
1> T=const wchar_t *
1> ]
1>Done building project "XXX.vcxproj" -- FAILED.
I have rebuilt wx 3.0.4 from scratch and the problem still exists. Does anyone have a fix for this? Or possibly an idea where I may start to resolve the error?
Thank you,
I am experiencing a problem with Visual Studio 2017. I have a wx 3.0.4 install that worked great under VS2017 15.7. I recently installed updates to VS2017 to version 15.8.4. Now, when I attempt to build a rudimentary project, I get the message below:
1>c\wxwidgets-3.0.4\include\wx\wxcrt.h(487): error C3861: 'wxStrcoll': identifier not found
1>c\wxwidgets-3.0.4\include\wx\wxcrt.h(487): note: 'wxStrcoll': function was not declared in the template definition context and can be found only via argument-dependent lookup in the instantiation context
1>c\wxwidgets-3.0.4\include\wx\wxcrt.h(496): note: see reference to function template instantiation 'int wxStrcoll_String<const wchar_t*>(const wxString &,const T &)' being compiled
1> with
1> [
1> T=const wchar_t *
1> ]
1>Done building project "XXX.vcxproj" -- FAILED.
I have rebuilt wx 3.0.4 from scratch and the problem still exists. Does anyone have a fix for this? Or possibly an idea where I may start to resolve the error?
Thank you,
Re: Issue with Visual Studio 2017 15.8.4?
Can you reproduce the issue using the bundled minimal sample?
I could not with MSVC 15.8.4 (Express) with Debug configuration and Platform Toolset v141.
I could not with MSVC 15.8.4 (Express) with Debug configuration and Platform Toolset v141.
Re: Issue with Visual Studio 2017 15.8.4?
I am having trouble with the minimal sample. It is wanting 32 bit wx and I have built x64 lib and DLL. I am going to build the 32 bit objects and try it out.
Re: Issue with Visual Studio 2017 15.8.4?
Oops, I forgot to write that I tested only the default 32-bit build.
Re: Issue with Visual Studio 2017 15.8.4?
Ok, I am going to apologize right up front. I must be missing a key step here. I have built the 32bit stuff. I pulled over the minimal project and added it to my current solution. I also tried the minimal sample as it's own solution. I get an RC1110 error when I do a build. The error reads Could not open ..\..\samples\sample.rc.
Re: Issue with Visual Studio 2017 15.8.4?
The VS project files for all samples use relative paths for include, library and resource directories. If you move them, you need to adjust these under:
C/C++ -> General
Linker -> General
Resources -> General
C/C++ -> General
Linker -> General
Resources -> General
Use the source, Luke!
Re: Issue with Visual Studio 2017 15.8.4?
That resolved my issues. Thank you again. I knew I had something messed up. Been looking at this for too long I guess...
I have a couple follow up questions as I am still learning as I go:
I noticed that the project settings for the additional include directories referenced $(WXWIN)\lib\{type of build}\mswud?
Foolish me, I always assumed include directories were for header files... Is this added to the additional include directories so that the compiler can find the wx object definitions?
Also, in the 3.0.4 install notes it states:
Microsoft Visual C++ users can simplify the linker setup by prepending
"$(WXWIN)/include/msvc" to the include path (it must come before the
"$(WXWIN)/include" part!) and omitting the last step: the required libraries
will be linked in automatically using the "#pragma comment(lib)" feature of
this compiler.
Based on my understanding, I would not need to add the additional libraries in Linker -> Input -> Additional Dependencies
Is this correct? If so, I assume the source code would need the "#pragma comment(lib)" preprocessor directive specified for the correct libraries. Something like:
#ifdef _DEBUG
#pragma comment(lib, "wxbase30ud.lib")
#else
#pragma comment(lib, "wxbase30u.lib")
#endif
What if you are running with a DLL build?
Thank you for all the assistance.
I have a couple follow up questions as I am still learning as I go:
I noticed that the project settings for the additional include directories referenced $(WXWIN)\lib\{type of build}\mswud?
Foolish me, I always assumed include directories were for header files... Is this added to the additional include directories so that the compiler can find the wx object definitions?
Also, in the 3.0.4 install notes it states:
Microsoft Visual C++ users can simplify the linker setup by prepending
"$(WXWIN)/include/msvc" to the include path (it must come before the
"$(WXWIN)/include" part!) and omitting the last step: the required libraries
will be linked in automatically using the "#pragma comment(lib)" feature of
this compiler.
Based on my understanding, I would not need to add the additional libraries in Linker -> Input -> Additional Dependencies
Is this correct? If so, I assume the source code would need the "#pragma comment(lib)" preprocessor directive specified for the correct libraries. Something like:
#ifdef _DEBUG
#pragma comment(lib, "wxbase30ud.lib")
#else
#pragma comment(lib, "wxbase30u.lib")
#endif
What if you are running with a DLL build?
Thank you for all the assistance.
Re: Issue with Visual Studio 2017 15.8.4?
If you check the folder, you will learn that it contains header files only (and build.cfg for people using configure?), with build options specific to that build.amduke65 wrote:I noticed that the project settings for the additional include directories referenced $(WXWIN)\lib\{type of build}\mswud?
Foolish me, I always assumed include directories were for header files... Is this added to the additional include directories so that the compiler can find the wx object definitions?
As written above, the setup.h included from that folder takes care or linking the required wxWidgets and Windows libraries, the libraries matching the build application uses are automatically and properly selected, based on the defines in your project such as _DEBUG or WXUSINGDLL. Again, if you look at the file there, it is pretty clear what is going on. Of course, you don't have to, it works as expected. AFAIK, when using this feature, you also do not need to add the build-specific folder to your include paths, the matching build-specific setup.h is included automatically.amduke65 wrote:Also, in the 3.0.4 install notes it states:
Microsoft Visual C++ users can simplify the linker setup by prepending
"$(WXWIN)/include/msvc" to the include path
Re: Issue with Visual Studio 2017 15.8.4?
Thank you for the explanation. This helped clarify some things for me.
-
- Filthy Rich wx Solver
- Posts: 235
- Joined: Fri Sep 14, 2012 8:26 am
- Location: Kontich, Belgium
- Contact:
Re: Issue with Visual Studio 2017 15.8.4?
Guys,
I'm recompiling a dll in VisualStudio 2017 (previously compiled with VS2010) and get a similar error on wxStrcoll 'identifier not found' (see image). I used the precompiled wxWidgets 3.0.4 for VS2017 32bit, while possibly using VS2017 64bit. So I'm wondering if this is the origin of that problem ?
I'm recompiling a dll in VisualStudio 2017 (previously compiled with VS2010) and get a similar error on wxStrcoll 'identifier not found' (see image). I used the precompiled wxWidgets 3.0.4 for VS2017 32bit, while possibly using VS2017 64bit. So I'm wondering if this is the origin of that problem ?
Re: Issue with Visual Studio 2017 15.8.4?
Hi,
Yes, if you are building sample/your code the prebuilt libraries or the stuff you built yourself should match.
Thank you.
Yes, if you are building sample/your code the prebuilt libraries or the stuff you built yourself should match.
Thank you.