Windows version still tries to link against dxerr.lib

[JPGygax68]

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 reads

  list(APPEND EXTRA_LIBS dinput8 dxguid dxerr)

needs to be changed to

  list(APPEND EXTRA_LIBS dinput8 dxguid)

to make the linker error LNK1104 go away.

[davidsiaw]

Thanks.

[davidsiaw]

Oops. Please file a pull request.

[Alan-FGR]

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.

[davidsiaw]

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.

[Alan-FGR]

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.

[hibengler]

I am using the OpenGL ES 2.0 interface, and cross compiling with mingw64, So I don't run into this.

[Alan-FGR]

If this isn't fixed in the repo I could make a quick repro.