Loading issues with the default bundled glfw3.dll on windows

[kohlmannmark]

While using the package in an anaconda environment (pip installed the glfw package into anacona env), I ran into an issue where ctypes.CDLL wouldn't load the bundled dll.

Downloading the glfw3 official precompiled binaries and replacing the bundled binary with the 64 bit lib-vc2015 build (my system specifics) eventually solved the problem, but I'm raising the issue so that if others run into this kind of problem, they may have a shortcut.

Or maybe there's a convenient solution to this, I'm not sure :)

Thanks anyways!

[FlorianRhiem]

Hello @kohlmannmark, thank you for reporting this issue!

For 64bit I am using the VC 2012 build from the glfw3 precompiled binaries. If you don't have the "Microsoft Visual C++ 2012 Redistributable (x64)" installed on your system, that might cause the problem loading the library. Could you please check whether it's installed or not? If installed, you should find it in the list of "Apps & features" in the Windows 10 settings along with the other Visual C++ redistributables.

If this is the cause of this, I'm not sure what would be the best way to fix it:

• As far as I know, redistributing those libraries by myself as part of the package is not permitted by Microsoft, and triggering a system-wide install of software like that isn't something I'd want a Python package to do.
• I could switch to another version of the library, but then others who don't have the VC 2015 libraries would have the same problem. It might still be better, as the official Python binaries for current versions seem to be built with VC 2015, so more users might have those libraries installed.
• Including all variations of the prebuilt binaries and then testing which one can be loaded should work, but it would lead to a very large wheel for Windows with little benefit, so I don't really want to do that.

Using the VC 2015 libraries and adding a note to the README sounds like an improvement, even if it isn't perfect, but if anyone has a better idea, let me know!

[kohlmannmark]

Hi @FlorianRhiem, I checked, and indeed my system was missing VC2012 (had 2010, 2013 and onwards, but not that specific build). I think the lack of people encountering this issue means that this is not a real problem right now, so maybe leaving everything as is, and mentioning this specific case in the readme would be a good enough solution for now.

[FlorianRhiem]

I've opened a PR and you can find the proposed README text here. Please let me know if the text would have solved/avoided the issue.

[kohlmannmark]

Thanks, it's perfect, this makes it all clear. From my part we can close this issue.

[chris-stones]

I see this issue is already Closed. But...
When re-distributing the runtime (Microsoft Visual C++ 2012 Redistributable (x64)) is not feasable, I believe it is common practice to compile with the '/MT' switch (rather than the default /MD).

If memory serves... In the Release configuration, change the setting at Properties->Configuration Properties->C/C++->Code Generation->Runtime Library. to Multi-threaded (/MT)

The final DLL will nolonger require any specific visual studio runtimes, At the cost of a slightly larger DLL. I would guess this is probably how the DLL's available on the main site are built ... But ive not checked.

Commenting because I also came across this issue.

[FlorianRhiem]

Hello Chris, I use the precompiled glfw3 binaries, I do not compile them myself. You could suggest setting this flag in the glfw repository.