Sign in to follow this  
viper110110

error LNK2019 with D3dcompiler.h

Recommended Posts

I am trying to port the tutorial at http://www.rastertek.com/dx11tut04.html from windows 7 to windows 8. Now that d3dx11async.h is deprecated, I am trying to use D3dcompiler.h. I got the win32 tutorials from the microsoft site and tried to copy the CompileShaderFromFile method found in tutorial 7. Everything compiles fine but when it tries to link I get the error

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.

Share this post


Link to post
Share on other sites
[quote name='viper110110' timestamp='1347858569' post='4980783']
Welcome to C++, where the code's made up and the errors don't matter.
[/quote]
Or rather, where errors relating to anything nontrivial are useless [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img]

Share this post


Link to post
Share on other sites
That error translates to
The used function "[font=courier new,courier,monospace]ColorShaderClass::InitializeShader[/font]" calls "[font=courier new,courier,monospace]ColorShaderClass::CompileShaderFromFile[/font]", but this function is missing. Please implement this function.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Oh, and if you happen to try to run a deployed Win8RT-application that did link to D3DCompiler.lib, you'll get this cryptic error:

[img]http://julmar.com/blog/mark/wp-content/uploads/2012/08/vserr_metro.png[/img]
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

Share this post


Link to post
Share on other sites
[quote name='viper110110' timestamp='1347858569' post='4980783']
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.
[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='Deft' timestamp='1347869010' post='4980805']
[quote name='viper110110' timestamp='1347858569' post='4980783']
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.
[/quote]

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.
[/quote]
Yes, I interpreted it as the library I had included didn't have the function I wanted.

[quote name='clb' timestamp='1347867723' post='4980801']
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.
[/quote]

I should be ok for now as I'm just making a level editor. For my game I plan to use precompiled shaders.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this