Open noodlecollie opened 6 years ago
Download "dependency walker". It helps to understand what's wrong with DLL.
It's taken a day of wrangling it, but I finally got the dependency walker working and it's actually really useful! Thanks for that tip. (The official site is waaaaay out of date, so I had to use these downloads: https://zzz.buzz/2017/05/18/download-dependency-walker/)
Turns out the confusion was because xash_sdl.dll
also required SDL.dll
, but the error made it appear that the Xash DLL itself was unable to be found. This also occurred again with the client.dll
requiring VGUI.dll
. I'd not copied these into the binary directory because they were part of the automatically downloaded dependencies, so I had assumed they'd just be taken care of.
I might add some of this info to the Build & Running wiki page, so it's clearer what needs to be done for Windows.
SDL2 and VGUI dlls are copied by "install". Just use it.
Visual Studio 2017 with CMake support does have a special button for it. CMake alone creates a project "INSTALL.vcxproj" for it.
I have also encountered the error. Xash3D's message is misinformative here.
Unfortunately I think Xash just does the best it can with the error message that Windows gives back - it's Windows that's misinformative because it doesn't tell you which of the sub-dependencies wasn't found.
To be honest I'm not overly familiar with Cmake, so I didn't know that "install" was still applicable when debugging and not just when installing a full release build.
Windows does not tell broken sub-dependencies in LoadLibrary, it just returning some error number to GetLastError
Perhaps I'm missing something really obvious here, but if I compile master on Windows, copy the DLLs to the executable folder and attempt to run the exe, I get the following error:
It originates from
xash.c:115
:Evidently Windows is unable to find the DLL, even though it's present next to the executable. Putting DLLs into the executable folder worked for me in the past, and I've tested things like making sure the current working directory for the VS debugger is set to point at that directory as well, but no luck.