I am running a DirectX 11 application on windows 7 and visual studio community 2015 RC. I'm still using functions from the DX SDK. It worked fine on VS2013 but when I switched over I get only the following error:
Error LNK2019 unresolved external symbol __vsnprintf referenced in function "long __stdcall StringVPrintfWorkerA(char *,unsigned int,unsigned int *,char const *,char *)" (?StringVPrintfWorkerA##YGJPADIPAIPBD0#Z) Ancora D:\Moody\Moody\Projects\Projects\Ancora\Ancora\dxerr.lib(dxerra.obj) 1
I only use the DXGetErrorDescriptionA function from the dxerr library and when I comment it out, the program compiles fine. I have no idea what's wrong but it can't be from the DX SDK or otherwise the other functions would fail right?
I experienced the same problem using DXGetErrorMessage() with Dx9 and found out that MS have provided an additional library to include in the Additional Dependencies properties page to address this problem. The library name is: legacy_stdio_definitions.lib
Adding this resolved the issue for me.
just add
#pragma comment(lib, "legacy_stdio_definitions.lib")
https://msdn.microsoft.com/en-us/library/bb531344.aspx
Instead of hacking dxerr.lib manually, you could add
#include <Windows.h>
#include <stdio.h>
int (WINAPIV * __vsnprintf)(char *, size_t, const char*, va_list) = _vsnprintf;
somewhere in your code
The legacy DirectX SDK is quite old, and dxerr.lib in the DXSDK is not compatible with VS 2015's C Runtime as you have encountered.
In general static libraries with code in them don't mix well from different versions of the compiler. Most of the .libs in the legacy DirectX SDK work with VS 2015 because they are import libraries for dlls or all data libraries and therefore contain no code at all. The DXSDK has not been updated since VS 2010.
Aside: The VS team has made a heroic effort to keep the Visual C/C++ Runtime link compatible between VS 2015 Update 3, VS 2017, and VS 2019 per Microsoft Docs. This is not the normal pattern.
Be sure to read the instructions on Microsoft Docs on the proper way to mix the legacy DirectX SDK with the Windows 8.x SDK used by VS 2015. You are presumably using something else from the legacy DirectX SDK in this project besides dxerr.
I have implemented a version of DXERR that you can build from source in your project to remove this dependency of the legacy DirectX SDK. See this post for details. That said, I purposely only supported Unicode (the W version). You can work out how to make the ANSI (the A version) easily enough, but it would be best if updated your app to use Unicode.
See Where is the DirectX SDK (2021 Edition)? and DXUT for Direct3D 11.
UPDATE: As noted in another answer linking with legacy_stdio_definitions.lib should make the old legacy DirectX SDK version of dxerr.lib link again with VS 2015/2017. That said, you should work on removing dependencies on the legacy DirectX SDK as much as possible and DXERR is easily replaced by your own module. See Living without D3DX.
The DirectX libraries you are using are compiled with an older version of Visual Studio than you are using. Microsoft sometimes makes changes to their C runtime, creating incompatibilities between libraries compiled with different versions. __vsnprintf was an internal symbol in older versions of their C runtime, it does not exist in the 2015 RC version.
Unfortunately, dxerr.lib (along with d3dx11.lib) have been deprecated. You have two options - you can switch back to VS2013 or you can stop using functionality from dxerr.lib. The latter is probably better, because you can duplicate its functionality by using FormatMessage now (more info in the linked article).
HACKY but you could patch dxerr.lib.
Replace __vsnprintf with _vsnprintf (with a null at the end to account for the removed underscore at the beginning)
You can change the Platform Toolset from Visual Studio 2015 to Visual Studio 2013 and then it compiles.
The Platform Toolset is found on the General tab of the Project Properties.
Related
I'm using several libraries built through vcpkg (such as civet-web and prometheus-cpp), against my Visual C++ projects. When building x86 all is perfect, in x64 I get a bunch of linker errors:
error LNK2001: unresolved external symbol __CxxFrameHandler4
Searching online all references to this symbol/error are about specific projects, I cannot find what __CxxFrameHandler4 is and what problem this error is highlighting. I don't know if it's a problem with the way vcpkg is building the library, or a problem in my project or how to start looking for a solution.
I did find this blog article but it is in reference to a preview of VS2019, I cannot find any settings related to it: https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/
If anyone can explain what this is all about it would be a big help.
I faced the same issues when trying to install and use cpr with vcpkg. I wanted to use cpr library in a VS2015 project.
Reason: I had VS2019 installed. vcpkg uses latest version of toolset Visual Studio.
Resolution: Add your own triplet or change existing such a way that your specified toolset is used. Adding did not work in my case so I changed existing "triplet" files in triplet folder in vcpkg. I wanted vcpkg to use toolset that comes with VS2015 (It's V140)
Content of x86-windows.cmake file
set(VCPKG_TARGET_ARCHITECTURE x86)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)
set(VCPKG_PLATFORM_TOOLSET "v140")
set(VCPKG_DEP_INFO_OVERRIDE_VARS "v140")
Content of x64-windows.cmake file
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)
set(VCPKG_PLATFORM_TOOLSET "v140")
set(VCPKG_DEP_INFO_OVERRIDE_VARS "v140")
A more general answer is that this happens if you are mixing objects that were built with different platform toolsets, e.g.,
Visual C++ 2015 (v140)
Visual C++ 2017 (v141)
Typically, you (or someone else) may have built a dependency of your project with a different compiler version (platform toolset), and the fix it to change the platform toolset of either your project or the dependency (or use the correct build of the dependency, if you used a pre-built package)
I think you pointed out the right article which is
https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/
I faced a similar issue in linking 64-bit library built with VC143 toolset with a 64-bit Application built with VC141 toolset.
After adding the following properties to VC143 built static library project, I was able to build the application. This disables the new feature mentioned in the above article (Exception Handling Smaller)
VS2019->Properties->C/C++->Command Line add '-d2FH4-'
VS2019->Properties->Linker->Command Line add '-d2:-FH4-'
Visual Studio 2017 RC includes much tighter CMake integration, allowing one to skip the intermediate step of generating project/solution files and use CMake effectively as the project file itself. There is sufficient documentation from Microsoft for using these features with regular C++ files, and there is sufficient documentation on this website (example) for making CUDA and Cmake play nicely, when it comes to linking CUDA code to C++ code.
What I can't find information on is how to make CMake, Visual Studio 2017 RC, and CUDA 8.0 all play nicely. This is a difficult problem, because 2017RC has no integration for the CUDA SDK anyways, and I was hoping to use 2017RC so that my C++ interface to the CUDA code could use C++14 and/or C++17. I'm working on the beginning of a large project that will primarily involve writing a static CUDA library that is accessed through C++: so, I'd like to get the CMake to take care of compiling my CUDA sources into a static library, and for it to help with feeding the linking information to Visual Studio. So far, I haven't had any success with using FindCUDA's various features to accomplish this, but I'm assuming that's due to a misunderstanding on my part. I've read through the documentation on separable compilation from Nvidia, but that wasn't helpful for figuring out CMake.
Further, whenever I try to use CMake in VS2017RC, I still end up with the various vcxproj files that CMake likes to spit out. Is this due to an error on my part? How do I edit the build command arguments, or CMakeLists.txt, to get the functionality demonstrated here to work?
The very short (and only at the time of writing) answer is that you can't. CUDA 8 doesn't support VS2017. Only VS2015 is presently supported.
You can always find the compiler/IDE versions which the release version of CUDA supports here
Edit to add that the CUDA 9 release will add official support for VS2017.
All you need to do is set the CUDA_HOST_COMPILER variable to a supported compiler for example the visual studio 2015 compiler.
In my case this is:
C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe
As both runtime libraries are binary compatible you can use the 2015 compiler within CUDA and compile all the rest of the application with the 2017 compiler.
I want to use std::experimental::optional, but MSVS 2013 tells me it can't find the header.
Why isn't it there?
Can I roll my own based on code elsewhere? The C++14 proposal maybe?
std::experimental::optional originates from the Boost.Optional library, and this implementation works well in Visual C++ 12.0 (though it differs a little). Reference single-header implementation, based on the N3793 proposal paper, can be found here.
The latest list of supported C++11/14/1z core and library features that are shipped with Visual Studio can be found from the Visual C++ Team blog, from this post in particular. A set of header files of the Standard Library implementation (and some extensions) from Microsoft can be viewed here.
I've found that this implementation compiles with MSVC2013. Note that only compiles, everything else isn't guaranteed.
https://github.com/mapbox/variant/blob/master/include/mapbox/optional.hpp
I was using this one for msvc2015 and it worked:
https://raw.githubusercontent.com/akrzemi1/Optional/master/optional.hpp
The requirements listed in the 3ds Max SDK state that plug-ins for 3ds Max 2011 must be built with Visual C++ 9.0 (Visual Studio 2008).
If I create a DLL with a different version of Visual C++, won't the binary be identical? Is this simply a matter of choosing the right compiler settings?
What problems will I run into if I try to build a plug-in using Visual C++ 2010 (Visual Studio 2010)?
I don't know specifically for 3ds Max, but the usual reason is the C Runtime library. If the host application uses the DLL version of the CRT, then plugins will also need to use the same version.
Otherwise, imagine the case where your plugin creates some memory using malloc(), and passes it to the host application, which uses it and then calls free(). If your plugin and the host application are using different CRTs, the host's call to free() will fail or crash because it wasn't the host's CRT that malloc()ed that block of memory.
The binary won't be identical but the binary interfaces should be, which is what you need.
The reason you can't use VS2010 is because it is not yet production quality. They think you should wait for VS2010 SP1 at a minimum.
You think they are just being obstinate and stubborn, eh? Ruining all your fun. They have reasons. Good ones.
Because of bugs like this:
https://connect.microsoft.com/VisualStudio/feedback/details/565959
I use both visual studio 2008 and 2010 for plugin development.
Only difference I've seen is that the user need the vs c++ runtime version for 2010\2008.
But there might be pitfalls - but I have not encountered any problems with it yet.
C++ doesn't have a standardised binary interface. The compiler "mangles" each symbol name (i.e. each function or static data) to include information about namespaces and signature, so that namespaces, argument overloading, &c. can work. Each compiler is free to decide how to do this. Different MSVS compiler versions do name mangling in different ways, so in general you can't link a C++ library compiled with 2005 and a library compiled with 2008 together: this includes loading a 2008 DLL from a 2005 executable (for example). You can do this if the interface between the libraries is C, as long as the relevant functions are marked with extern "C" to prevent name mangling. And in practice the differences are not always that great: for example, I never had trouble using VS2005 SP1 to compile a library for 3ds Max 9, which supposedly requires VS2005 with no service pack.
Microsoft is trying to fix this incompatibility, so in VS2010 they introduced an option, so VS2010 can produce binaries compatible with VS2005 programs or VS2008 programs (maybe some earlier versions too, I forget). If you have to create a plugin to work with multiple 3ds Max versions, and you don't get caught out by any VS2010 bugs, this is probably a good option. Also, the Intel C++ compiler has a mode where it produces binaries that are compatible with an MSVS version of your choice, which might be a better option for you if it's for hobby use or you can afford the slightly expensive price tag. (They achieve this by copying the way MSVS does name mangling.)
What are the basic steps to compile an OpenGL application using GLUT (OpenGL Utility Toolkit) under Visual C++ Express Edition?
If you don't have Visual C++ Express Edition (VCEE), download and install VCEE.
The default install of Visual C++ Express Edition builds for the .Net platform. We'll need to build for the Windows platform since OpenGL and GLUT are not yet fully supported under .Net. For this we need the Microsoft Platform SDK. (If you're using an older version of VCEE, download and install the Microsoft Platform SDK. Visual C++ Express Edition will need to be configured to build for Windows platform. All these instructions are available here.)
If you don't have GLUT, download and unzip Nate Robin's Windows port of GLUT.
Add glut.h to your Platform SDK/include/GL/ directory
Link the project with glut.lib. (Go to VCEE Project Properties -> Additional Linker Directories and add the directory which has glut.lib.
Add glut.dll to the Windows/System32 directory, so that all programs using GLUT
can find it at runtime.
Your program which uses GLUT or OpenGL should compile under Visual C++ Express Edition now.
The GLUT port on Nate Robin's site is from 2001 and has some incompatibilities with versions of Visual Studio more recent than that (.NET 2003 and up). The incompatibility manifests itself as errors about redefinition of exit(). If you see this error, there are two possible solutions:
Replace the exit() prototype in glut.h with the one in your stdlib.h so that they match. This is probably the best solution.
An easier solution is to #define GLUT_DISABLE_ATEXIT_HACK before you #include <gl/glut.h> in your program.
(Due credit: I originally saw this advice on the TAMU help desk website.)
I've been using approach #1 myself since .NET 2003 came out, and have used the same modified glut.h with VC++ 2003, VC++ 2005 and VC++ 2008.
Here's the diff for the glut.h I use which does #1 (but in appropriate #ifdef blocks so that it still works with older versions of Visual Studio):
--- c:\naterobbins\glut.h 2000-12-13 00:22:52.000000000 +0900
+++ c:\updated\glut.h 2006-05-23 11:06:10.000000000 +0900
## -143,7 +143,12 ##
#if defined(_WIN32)
# ifndef GLUT_BUILDING_LIB
-extern _CRTIMP void __cdecl exit(int);
+/* extern _CRTIMP void __cdecl exit(int); /* Changed for .NET */
+# if _MSC_VER >= 1200
+extern _CRTIMP __declspec(noreturn) void __cdecl exit(int);
+# else
+extern _CRTIMP void __cdecl exit(int);
+# endif
# endif
#else
/* non-Win32 case. */