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 have following 2 questions wrt to Windows SDK and Platform toolsets and C/C++ runtime library.
a) What is the relation of Windows SDK with C/C++ runtime and platform toolset?
Is it correct to say that BOTH C++ runtime libraries & platform toolsets are provided by Windows SDK?
Since we mostly deal with Platform toolsets from within the Visual Studio project settings, so want to understand that whether under the hood does the Visual Studio controls the C++ runtime library and platform toolset versions by installing the required version of Windows SDK?
b) Another thing i wanted to clarify was that if it is correct to say one version of platform toolset can work with different version of Windows SDK OR these are totally unrelated?
eg. in my Visual Studio i see that 'Windows SDK version' is Windows 10 and Platform toolset is v142. Can i set the 'Windows SDK version' to Windows 8.1 and keep the toolset as v142? If yes, then what does it mean?
This is confusing me a lot and i can't seem to get the correct picture with so many different explanations from different people.
TL;DR: If you are using Visual C++, and use the standard REDIST instructions from Microsoft Docs, then these details shouldn't really matter to you.
With VS 2015 and later, the "C/C++ Runtime" has been refactored into three pieces:
UCRTBASE.DLL is part of the OS and serviced through Windows Update. There are 'down-level' versions of it included in the Visual C++ REDIST package, but generally you should think of this as the "OS" part. This is the "C Runtime". These headers, import libraries, and are in the Windows 10 SDK. You can find the source for it there as well C:\Program Files (x86)\Windows Kits\10\Source\<version>\ucrt.
MSVCP*.DLL This is the "C++ Runtime" library, basically stuff like std::vector et al. The headers, import libraries, and such are in the Visual C++ product. You can find the source to it on GitHub per this blog post.
VCRUNTIME*.DLL has the entry-points needed at runtime for the Visual C++ compiler language features.
There are also a few auxiliary libraries as well for specific scenarios:
VCCORLIB*.DLL is used for C++/CX extensions (a.k.a. /ZW)
VCAMP140.DLL is used for C++ AMP
VCOMP140.DLL is used for OpenMP
CONCRT*.DLL is used to implement C++11 <thread> on Windows XP (not used on newer versions of Windows; it's delay loaded if required)
See this blog post and this one.
Essentially the C runtime (the UCRTBASE) part is a simple extern "C" interface so the ABI is well-defined, and thus is usable with multiple versions of Visual C++ and even other compilers. Exactly which version of the UCRT you are using is therefore primarily depending on the OS and the Windows 10 SDK you are using via WindowsTargetPlatformVersion. You can applocal deploy UCRT as well per this blog.
The C++ Runtime (MSVCP*.DLL) includes a lot of inlines and exposed memory layouts, and historically there was a breaking change between between Visual C++ versions. That said, for VS 2015 Update 3, VS 2017, and VS 2019 the VC team has made a point of keeping 'binary compatibly' here meaning that if you have a static library that uses C++ std namespace components from a PlatformToolset of v140/v141, it will successfully link with a later version of Visual C++ up through v142. It's not clear that this will hold in the future, but it is true for this particular set of releases per Microsoft Docs.
The VCRUNTIME*.DLL needs to match the version of the Visual C++ compiler you are using to build the final link, so this is very much intended to match your PlatformToolset.
I need to integrate the Intel RealSense C++ library (legacy 2016 R3 not the current 2.0 SDK) to an already existing application built with Qt MinGW g++ 32-bit (installed by Qt5.11 offline installer)
basically, they provide the headers and some .lib files to compile and link applications
when I try to compile the Segmentation example in Visual Studio, they work, (they provide a .props file that I can add to the Visual Studio Solution's Project's Property Manager, btw, I am using Visual Studio Community 2017 on Windows 10 Home 64-bit), but, the application I am developing was made using QtCreator so I need to be able to compile with QtCreator, and migrating the build to Visual Studio might not be a viable solution
if I try to compile the Segmentation example with MinGW (32-bit) in QtCreator (installed by Qt5.11 offline installer) I get error messages like this one
C:\src\Debug\app\main.cpp:34: error: undefined reference to `UtilCmdLine::UtilCmdLine(Intel::RealSense::Session*, int)'
and even if I try to use MSVC (64-bit) in QtCreator (installed by Qt5.11 offline installer) (which is not really a great option)
I get error messages like this one
C:\src\Debug\app\main.cpp.obj:-1: error: LNK2019: unresolved external symbol PXCSession_CreateFromPath referenced in function "public: static class Intel::RealSense::SenseManager * __cdecl Intel::RealSense::SenseManager::CreateInstance(wchar_t const *)" (?CreateInstance#SenseManager#RealSense#Intel##SAPEAV123#PEB_W#Z)
for several symbols
has anyone solved a similar problem?
MinGW I think I understand not working, because of MSVC symbol mangling and a general different ABI, and because the tools to work with .lib files in MinGW are no longer being available (at least not in the official website), but why is MSVC not working? am I missing something that Visual Studio has that QtCreator does not?
would there be a way to make something like a wrapper library in visual studio so that I can use in MinGW? I saw some people who had similar problems with .lib files being told to use a COM style interface if they could
I saw that being the
just to clarify, I'm not sure if it's a problem introduced by the Qt libraries but there is some of the application's code just doesn't compile correctly with MSVC, so for now, I'd prefer a way to compile with MinGW in QtCreator, though we might eventually get it to work with both compilers (or at least try to)
I have an application written in QT. Previously I was using Visual Studio 2012 and Qt 5.3.1 after which I recently upgraded to Visual Studio 2015 and QT 5.6. I would previously provide msvcp110 and msvcr110 as part of the installation (I know that wasn't the best practice but I got away with it).
After upgrading I had to now install VC++ 2015 because of the changes with VS 2015. I don't mind the changes and currently providing redist packages to be installed.
The problem I am facing is that, I do have to provide VC++ 2012 as well and recently running the software in Windows 8.1 Pro, I was asked to provide VC++ 2013 as well (never used VS2013 for compiling). The diagnosis was from dependency walker and google. Not only that, I had to install x86 and x64 of all the 3 versions of VC++ for the software to start (wouldn't even start to be honest).
Why do I need VC++ 2012 and 2013 when I now use only Visual Studio 2015?
How do I get rid of the other redist packages? Is it some code I have written which is dependent? If yes any chance I can find out?
Why do I need to provide both the 32 and 64 bit versions when I compile strictly in the 64 bit compiler?
Any way to diagnose without dependency walker? Can there be some logging when the application refuses to start at all?
Apologies for the long post, but any light here can restore my sanity.
Thanks in advance.
You are using DLLs linked to the older runtime. You can use Dependency Walker on your development machine to track this down, shouldn't need to install any tools on a customer machine for that.
Migrate all the files shipped with your application to a version built against VC++ 2015.
You didn't provide any details that could reveal the reason.
For DLLs other than the language runtime library, you can use delay-loading and then be able to trap failure to load the library. You can't effectively delay-load msvcr*.dll though. One option would be to create a very thin EXE that uses no support DLL at all (either use pure Win32 API, or statically link the runtime) which does nothing except install an error handler and then load your main program which is now in the form of a DLL. Loading your main program DLL should be done either using delay-load linking or LoadLibrary()+GetProcAddress() -- either one will allow catching errors. This main program DLL would be free to import the runtime DLLs as usual.
I uploaded my (VS2013) project folder and provided it to the other members of my team, but when they tried to build/run it, using Visual Studio 2012 they got this error, it also happened on their version of Visual Studio 2013.
The program can't start because MSVCR100D.dll is missing from your computer. Try reinstalling the
program to fix this problem.
They reinstalled VS2010 but no go.
I also tried to statically link my project by using /MT in the Code Generation options but now I get:
Unresolved External Symbol __free_dbg libcmptd.lib cout.obj
....25 more...
How can I get it so my project can be build/ran on my team members pc? How do I resolve the unresolved externals? It seems to happen purely with regular Microsoft files.
You are mixing C++ libraries built with different versions of the compiler (and as we know some of them are linked against debug dynamic version of VC10 runtime library). This is not supported, as different compiler versions have different ABIs.
To fix the mess you need to find libraries built with parameters that match parameters of your project. They should be built:
with the same compiler version (ex. VS 2013)
with the same configuration (Debug/Release)
against the same platform (x86/x64/ARM)
against the same runtime library variant (static/dynamic + debug/release)
You could either try to find prebuilt versions on the web or to build libraries yourself from source codes. Often, you will want to have multiple configuration/platforms for your project and, thus, you will need multiple versions of your libraries.
If your search will not succeed (for example if there is no VS2013 build for a closed source library) you could roll back your project to another version of compiler and to start over.
Any attempts to link incompatible libraries even if somehow succeeded will lead to random crashes.
This message generally states that the dll is referred to directly or indirectly in your application and is missing.
The 'D' at the end show us this is the Debug version of the file, this is DLL file is provided with the Visual Studio 2010 installation. So the MSVCR100D.dll would be provided with the installation of Visual Studio 2010.
Of course, you could be missing other versions 2008 (MSVCR90D) 2010 (MSVCR100D) 2012 (MSVCR110D) or the 2013 (MSVCR120D), each dll is provided according to the Visual Studio version.
There are a few ways to solve this:
Check to be sure that you're compiling all the components of your
project in Release mode. If this does not solve the issue continue
to the next steps.
You could solve this locally by installing Visual Studio 2010 on your
machine. This is not what I would recommend, but it would surely
overcome the issue
You could also download the file from this third party website and
copy it to your projects bin:
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100d
This option is the LEAST recommended option.
Run dependency Walker and see what file depends on the MSVCR100D.dll
and the try and fix that file in order to break your dependency. You can download depends here: http://www.dependencywalker.com/
Check to be sure that you're project is linking the correct version of
the CRT and any other libraries you may be using (e.g., MFC, ATL,
etc.)
Note: Installing the redistributables alone will NOT solve this problem, since the redistributables only contain the release version of the file MSVCR100.dll (notice no 'D')
Would it be possible that in your project you are somehow using some component/library built with Visual Studio 2010, which requires the MSVCR100D DLL?
I need to modify the C runtime which ships with VS2010 because the 2010 CRT relies on functions released in Windows XP SP2, and I need to be able to deploy to Windows 2000.
Specifically, I need to remove any and all calls to EncodePointer and DecodePointer.
The source for the C runtime is included in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src, so it seems like it should be possible to build the runtime after slightly modifying the source.
Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only. (I cannot rely on the user installing the CRT on their system either).
With VS2008 and earlier, there was a tutorial in MSDN describing how to build the CRT, but I can't seem to find it for 2010.
Is such a thing possible?
Here's an MSDN link. It looks like you have to do it yourself in VS2010.
You can use the following compiler and linker options to rebuild the MFC, CRT, and ATL libraries. Starting in Visual C++ 2010, scripts for rebuilding these libraries are no longer shipped.
If it is a option, I would consider using the VC++ 2008 toolset within VS2010 instead of building a custom CRT. The procedure is explained here.
"Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only."
Since you only need static linking, you can try this trick to provide implementations of EncodePointer and DecodePointer.