Open JPGygax68 opened 9 years ago
Thanks.
Oops. Please file a pull request.
I can confirm this... if you build with DirectX though it won't try and link dxerr because it sets an internal flag to use the windows SDK as opposed to DirectX. If that lib isn't used though then it makes no sense to have it, otherwise it would be better to expose the option to force use win sdk. I'm only using SDL for input and windowing.
Hmm Is this still an issue in the latest SDL2? I seem to be able to build it just find at the moment, and I have recently updated to a later revision in hg.
I'm using release 2.0.8. If you build without the DirectX option it will not use the Windows SDK and still links the dxerr.lib from the old DirectX SDK. That's easy to see in CMakeLists. No biggie though, but I'm not using anything DirectX from SDL and if I disable the DirectX
option it says it can't find that dxerr.lib what's strange.
I am using the OpenGL ES 2.0 interface, and cross compiling with mingw64, So I don't run into this.
If this isn't fixed in the repo I could make a quick repro. :trollface:
I'm going to file this in with the official SDL forum as soon as I get posting rights there, but in the meantime, you might want to fix this in your mirror.
The problem occurs when building SDL using the Windows SDK version 8. This Microsoft blog post explains why
dxerr.lib
is no longer provided with the newer SDKs, and what functions (and macros) it used to contain.I searched the SDL code for calls to these functions, and found a few - all commented out; meaning that the current code no longer uses
dxerr.lib
at all.Unfortunately,
CMakeLists.txt
apparently was not updated to reflect that fact. The line that readsneeds to be changed to
to make the linker error
LNK1104
go away.