error LNK2019 with D3dcompiler.h
#1 Members - Reputation: 353
Posted 16 September 2012 - 02:48 PM
Error 1 error LNK2019: unresolved external symbol "private: long __thiscall ColorShaderClass::CompileShaderFromFile(wchar_t *,char const *,char const *,struct ID3D10Blob * *)" (?CompileShaderFromFile@ColorShaderClass@@AAEJPA_WPBD1PAPAUID3D10Blob@@@Z) referenced in function "private: bool __thiscall ColorShaderClass::InitializeShader(struct ID3D11Device *,struct HWND__ *,wchar_t *,wchar_t *)" (?InitializeShader@ColorShaderClass@@AAE_NPAUID3D11Device@@PAUHWND__@@PA_W2@Z) C:\Users\Daniel\Documents\Dropbox\Dev\DXEngineMaybeThisTime\DXEngine\DXEngine\ColorShaderClass.obj DXEngine
It appears that the files are not being included, but I went through the project properties of my project and tutorial 7 and made sure they were exactly the same, especially the linker input. I'm lost and clueless as to what to do.
#2 Members - Reputation: 353
Posted 16 September 2012 - 11:09 PM
Turns out my problem was forgetting MyClassName:: in front of the function, which was left out because I copied it out of the tutorial which had all the code in main.cpp.
#5 Members - Reputation: 1593
Posted 17 September 2012 - 01:42 AM
I think that's not an overly bad choice, it enforces people to take the more performant path, but what Microsoft completely screwed up in the process is that they don't have the ability to reflect shader code any more. That means that the functions D3DReflect et al. are no longer available, and you cannot ask what resources a shader contains or where they are bound to. I guess this is an amateur mistake they did, since the reflection features just happened to be in the D3DCompiler.dll and the whole dll was pulled. They did not even offer an alternative shader metainformation mechanism.
As a workaround, it is suggested that you implement your own shader metainformation file format that contains all the necessary information for reflection. At build time, you run the shaders through your own tool and generate this metafile as a preprocess step.
#6 Members - Reputation: 1593
Posted 17 September 2012 - 01:45 AM

without any hint to what caused it. Removing linkage to D3DCompiler.lib resolves this error. Took me a good day and a half to try to debug why the sample application worked and deployed correctly, but mine didn't and just mystically failed. The issue was the unsupported D3DCompiler.lib.
Edited by clb, 17 September 2012 - 01:46 AM.
#7 Members - Reputation: 218
Posted 17 September 2012 - 02:03 AM
Welcome to C++, where the code's made up and the errors don't matter.
Turns out my problem was forgetting MyClassName:: in front of the function, which was left out because I copied it out of the tutorial which had all the code in main.cpp.
If you don't know, what error matters, this is not mean that it's useless. Think you should try to understand how linker is working. If you've got unresolved symbol, then this means that you declared entity (such as method) and didn't implement it. Such error also could appear when you use library API without adding libraries themselves.
#8 Members - Reputation: 353
Posted 17 September 2012 - 12:54 PM
Yes, I interpreted it as the library I had included didn't have the function I wanted.
Welcome to C++, where the code's made up and the errors don't matter.
Turns out my problem was forgetting MyClassName:: in front of the function, which was left out because I copied it out of the tutorial which had all the code in main.cpp.
If you don't know, what error matters, this is not mean that it's useless. Think you should try to understand how linker is working. If you've got unresolved symbol, then this means that you declared entity (such as method) and didn't implement it. Such error also could appear when you use library API without adding libraries themselves.
Btw, just as a heads up, in Windows 8 WinRT-based applications, Microsoft decided to pull D3DCompiler.h/.lib/.dll altogether. This means that if you cannot compile shaders from strings (in memory or from file) at runtime, but you must compile them at authoring time and load in the compiled bytecode.
I think that's not an overly bad choice, it enforces people to take the more performant path, but what Microsoft completely screwed up in the process is that they don't have the ability to reflect shader code any more. That means that the functions D3DReflect et al. are no longer available, and you cannot ask what resources a shader contains or where they are bound to. I guess this is an amateur mistake they did, since the reflection features just happened to be in the D3DCompiler.dll and the whole dll was pulled. They did not even offer an alternative shader metainformation mechanism.
As a workaround, it is suggested that you implement your own shader metainformation file format that contains all the necessary information for reflection. At build time, you run the shaders through your own tool and generate this metafile as a preprocess step.
I should be ok for now as I'm just making a level editor. For my game I plan to use precompiled shaders.






