Manual Building using windows

[buschNT]

I tried the manual building as described (using Windows 8.1, Python2.7):

set INCLUDE=%INCLUDE%;<path to headers>
set LIB=%LIB%;<path to lib>
python setup.py build_ext -i

this however failed. With the following changes I managed to build it:

1. in setup.py change line 43 to: extra_link_args.append('-L%s' % (os.path.join(os.environ['GLFW_ROOT'], 'lib-vc2012'),))
2. set GLFW_ROOT=%GLFW_ROOT%; -> path to glfw3 main folder, which includes: "include" and "lib-vc2012"

After building it, I installed it: python setup.py install When I try to import cyglfw3 (import cyglfw3 as glfw), I get the following error:

Traceback (most recent call last):
  File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 4.0.6\helpers\pydev\pydevd.py", line 2217, in <module>
    globals = debugger.run(setup['file'], None, None)
  File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 4.0.6\helpers\pydev\pydevd.py", line 1643, in run
    pydev_imports.execfile(file, globals, locals)  # execute the script
  File "C:/.../test.py", line 5, in <module>
    import cyglfw3 as glfw
  File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 4.0.6\helpers\pydev\pydev_monkey_qt.py", line 71, in patched_import
    return original_import(name, *args, **kwargs)
  File "build\bdist.win32\egg\cyglfw3\__init__.py", line 7, in <module>
    # Copyright (c) 1999 by Secret Labs AB.
  File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 4.0.6\helpers\pydev\pydev_monkey_qt.py", line 71, in patched_import
    return original_import(name, *args, **kwargs)
  File "build\bdist.win32\egg\cyglfw3\glfw3.py", line 7, in <module>
  File "build\bdist.win32\egg\cyglfw3\glfw3.py", line 6, in __bootstrap__
ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.

I tried to provide the DLL by copying to different locations, however I could not manage to solve this problem yet. The "build\bdist.win32" folder is existing, but it's empty. Maybe you can help me fix this problem. Thanks.

Best regards, buschNT

[adamlwgriffiths]

Hmm, so theres 2 issues.

1. /LIBPATH isn't working for you.
2. Once built with -L instead, the DLL cannot be found.

I'm not sure where the DLL should be. I would have assumed %PWD% (I assume thats valid on windows) which would be the directory you're running it from.

Could setting %PATH% or %PYTHONPATH% help?

Can you confirm that you're using GLFW 3.1.

@filonik fixed the Win32 script for me. So it'd be great to get his input on this issue.

[filonik]

Yes, GLFW_ROOT is not defined automatically (there is no way it could be, since the Windows binaries are distributed in a simple zip-file). Therefore, if you have to rely on it, you need to set it manually, which seems to have worked for you.

Regarding the second issue, it sounds like the GLFW dll could not be found. I usually just place "glfw3.dll" from "lib-vc2012" in the same directory as the main python script.

Edit: Sorry, I only noticed now that you also had to change the linker flags. What compiler are you using?

[buschNT]

@filonik you are right. Placing the "glfw.dll" into the main folder worked, now. I'm quite sure I had it there at one point, but the error message showing the path led me in a wrong direction.

I used the VS2012 x86 Native Tools Command Prompt to compile it. However, I'm not 100% sure which compiler is used, since I have installed VCForPython27 and MINGW, too. (I don't know it it's possible to change the compiler of the Prompt)

@adamlwgriffiths after running one example it's quite easy to confirm that I'm using GLFW 3.1 ('GLFW3:', '3.1.1 Win32 WGL VisualC DLL')

I think it could be helpfull to mention (within the windows installation section) that it's necessary to set "GLFW_ROOT". For me it was not that obvious, since I'm not compiling that much stuff manually.

Thanks for the fast response.

[adamlwgriffiths]

Sorry about the GLFW_ROOT. I haven't been able to test on a Windows box yet.

I didn't think it would be required? %INCLUDE% and %LIB% should be sent to MSVC?

Does that mean that only GLFW_ROOT need be set? Not %INCLUDE% and %LIB% ?

[adamlwgriffiths]

Sorry, I'll re-open this until we've either sorted the docs to specify using GLFW_ROOT, or figured out what INCLUDE / LIB aren't enough.

[buschNT]

If you look inside the setup.py there is the "win32" section (here with the changed linker flag):

if 'win32' in platform:
    glfw_lib = 'glfw3dll'
    if 'GLFW_ROOT' in os.environ:
        extra_compile_args.append('-I%s' % (os.path.join(os.environ['GLFW_ROOT'], 'include'),))
        extra_link_args.append('-L%s' % (os.path.join(os.environ['GLFW_ROOT'], 'lib-vc2012'),))

the INCLUDE and LIB path are generated based on the GLFW_ROOT path. Hence, I only had to set the GLFW_ROOT, nothing else and it worked. If you want to use INCLUDE and LIB, it should be possible by changing the paths to something like that (not tested):

if 'win32' in platform:
    glfw_lib = 'glfw3dll'
    if ('INCLUDE' in os.environ) and ('LIB' in os.environ):
        extra_compile_args.append('-I%s' % (os.environ['INCLUDE'],))
        extra_link_args.append('-L%s' % (os.environ['LIB'],))

using INCLUDE / LIB could provide the advantage that you can choose the LIB subfolder, which are provided in the glfw3 windows zip, ( 'lib-vc2011', 'lib-vc2012', or 'lib-vc2013') manually.

[filonik]

I believe the idea behind the original INCLUDE / LIB was to use the default CL Environment Variables: https://msdn.microsoft.com/en-us/library/kezkeayy.aspx

One of the reasons I introduced GLFW_ROOT is because it also makes it easy to locate the GLFW headers when generating the bindings. However, ideally both methods should work or the documentation needs to be changed.

[adamlwgriffiths]

Exactly. I assumed INCLUDE and LIB would be automatically used by MSVC. Perhaps they aren't in this case. So I guess we should add the variables to the args Only question is if it needs to be -L or /LIBPATH. -L seems to look more consistent. Does it build if you use -L, filonik?

[filonik]

Afraid not, that's why I ended up using /LIBPATH.

LINK : warning LNK4044: unrecognized option '/LC:\Libraries\glfw\glfw-3.1.bin.WIN32\lib-vc2012'; ignored
LINK : fatal error LNK1181: cannot open input file 'glfw3dll.lib'
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\BIN\\link.exe' failed with exit status 1181

(Also, see https://msdn.microsoft.com/en-us/library/y0zzbyt4.aspx)

[adamlwgriffiths]

Strange! I guess we'll just have to put them all in. -L and /LIB. Should fix it.

On 10/04/2015, at 2:55 AM, filonik notifications@github.com wrote:

Afraid not, that's why I ended up using /LIBPATH. (See https://msdn.microsoft.com/en-us/library/y0zzbyt4.aspx)

LINK : warning LNK4044: unrecognized option '/LC:\Libraries\glfw\glfw-3.1.bin.WIN32\lib-vc2012'; ignored LINK : fatal error LNK1181: cannot open input file 'glfw3dll.lib' error: command 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.exe' failed with exit status 1181 — Reply to this email directly or view it on GitHub.

[filonik]

Well, the only sensible explanation for me is that buschNT and I somehow end up with different linkers. (For example, MINGW was mentioned, for which it makes sense to accept the -L option.) Specifying both command line options is a bit of a hack, since (in the best case scenario) it will cause unrecognized option warnings.

Edit: buschNT, can you post the output of running "python setup.py build_ext --inplace"?

[adamlwgriffiths]

We could potentially use something like this (http://stackoverflow.com/questions/724664/python-distutils-how-to-get-a-compiler-that-is-going-to-be-used) to detect the linker and put the vars in the appropriate options.

[adamlwgriffiths]

LINK : warning LNK4044: unrecognized option '/LC:\Libraries\glfw\glfw-3.1.bin.WIN32\lib-vc2012'; ignored

I just noticed that that says /LC:.... Did it convert the -L to /L, or is it a typo?

[buschNT]

@filonik here's the output from the console for "python setup.py build_ext --inplace" I set GLFW_ROOT before executing the command

1.) original version of "setup.py" (here it fails)

C:\test\cyglfw3-master>python setup.py build_ext --inplace
running build_ext
building 'cyglfw3.glfw3' extension
C:\Program Files (x86)\mingw\bin\gcc.exe -mdll -O -Wall "-IC:\Program Files\Anac
onda\include" "-IC:\Program Files\Anaconda\PC" -c cyglfw3/glfw3.c -o build\temp.
win32-2.7\Release\cyglfw3\glfw3.o -IC:\test\glfw-3.1.1.bin.WIN32\include
writing build\temp.win32-2.7\Release\cyglfw3\glfw3.def
C:\Program Files (x86)\mingw\bin\dllwrap.exe -mdll -static --entry _DllMain@12 -
-output-lib build\temp.win32-2.7\Release\cyglfw3\libglfw3.a --def build\temp.win
32-2.7\Release\cyglfw3\glfw3.def -s build\temp.win32-2.7\Release\cyglfw3\glfw3.o
 "-LC:\Program Files\Anaconda\libs" "-LC:\Program Files\Anaconda\PCbuild" -lglfw
3dll -lpython27 -lmsvcr90 -o C:\test\cyglfw3-master\cyglfw3\glfw3.pyd /LIBPATH:C
:\test\glfw-3.1.1.bin.WIN32\lib-vc2012
gcc: /LIBPATH:C:\test\glfw-3.1.1.bin.WIN32\lib-vc2012:
Invalid argument
dllwrap: gcc exited with status 1
error: command 'C:\\Program Files (x86)\\mingw\\bin\\dllwrap.exe' failed with ex
it status 1

2.) changed linker flag (which is working for me)

C:\test\cyglfw3-master>python setup.py build_ext --inplace
running build_ext
building 'cyglfw3.glfw3' extension
C:\Program Files (x86)\mingw\bin\gcc.exe -mdll -O -Wall "-IC:\Program Files\Anac
onda\include" "-IC:\Program Files\Anaconda\PC" -c cyglfw3/glfw3.c -o build\temp.
win32-2.7\Release\cyglfw3\glfw3.o -IC:\test\glfw-3.1.1.bin.WIN32\include
writing build\temp.win32-2.7\Release\cyglfw3\glfw3.def
C:\Program Files (x86)\mingw\bin\dllwrap.exe -mdll -static --entry _DllMain@12 -
-output-lib build\temp.win32-2.7\Release\cyglfw3\libglfw3.a --def build\temp.win
32-2.7\Release\cyglfw3\glfw3.def -s build\temp.win32-2.7\Release\cyglfw3\glfw3.o
 "-LC:\Program Files\Anaconda\libs" "-LC:\Program Files\Anaconda\PCbuild" -lglfw
3dll -lpython27 -lmsvcr90 -o C:\test\cyglfw3-master\cyg
lfw3\glfw3.pyd -LC:\test\glfw-3.1.1.bin.WIN32\lib-vc2012

Looks like I use MINGW. The installer I used is called "gcc-mingw-4.3.3-setup". I think it was form the following page: https://github.com/develersrl/gccwinbinaries But as mentioned above, I have installed "VCForPython27" too: http://www.microsoft.com/en-us/download/details.aspx?id=44266

[filonik]

@adamlwgriffiths I've actually specified -L, but it seems that the options parser converts it to /L internally. Regardless, thanks to buschNT's console output the case is pretty clear. In order to properly support MINGW alongside Visual Studio, the build scripts would have to be changed, so the correct command line options will be provided. Also, depending on the compiler, we should link the right version of GLFW binaries (lib-mingw, lib-vc2012, etc.).

@buschNT thanks for helping track down the issue!

[adamlwgriffiths]

Unfortunately, I'm not going to get a chance to look at this any time soon.

[Emilgardis]

I managed to install with cp35 on x64 by running python3.5 setup.py build_ext -i and then install as usual. Not sure how it worked but it did. However. Now I'm getting an import error on line 7 in __init__.py: ImportError: DLL load failed: The specified procedure could not be found. I noticed just now that there is no file in site-packages/cyglfw3 called glfw3. Is python importing from glfw.pyx?

::EDIT Oops just saw that that's exactly what @bushNT did for compiling, sorry

[Emilgardis]

Found the source of the problem. Loaded glfw3.dll (presumably) compiled for mingw, placed libvc12 dll inside cyglfw3 site and now it works. Also for my previous post I set the correct path of glfw3 to GLFW_ROOT

[adamlwgriffiths]

Can you specify what you did exactly, then I can update the README for Windows users.

Having to copy a DLL sounds like there's something not quite right.

[adamlwgriffiths]

Should be resolved in 5b363faa91e39d31f93ade0c7e931d52a1e1de17

[Emilgardis]

The problem with windows is that there is no real consensus/support for headers and libraries. What should be done is that pip provides a INCLUDE and LIB env var that tells the setup script where headers and modules could be found. Also the "place .dll in site" problem would be fixed easily by using that same var.

[adamlwgriffiths]

True. I think the current process should handle most cases. Any new ones can be addressed separately. I assume it would work for the above people who posted.

If it continues to be a problem, we can add setup time compiler checking (pretty nasty code), or even move away from Cython to ctypes bindings which are pretty trivial to maintain and install.

[adamlwgriffiths]

Feel free to re-open if you're not satisfied with the current solutions. I've closed on the assumption that it's resolved for most cases.