Cannot load zmq DLL on Windows 7 (64bit) with gvim/python (32bit)

[edouardp]

I am having a similar problem to other people here. In fact I think it is more or less issue 80, although that issue is closed.

I am running:

python 2.7.2    (http://python.org/ftp/python/2.7.2/python-2.7.2.msi)
ipython 0.12    (from http://archive.ipython.org/release/0.12/ipython-0.12.win32-setup.exe)
pyzmq 2.1.11  (http://cloud.github.com/downloads/zeromq/pyzmq/pyzmq-2.1.11.win32-py2.7.msi)
gvim 3.7.46     (ftp://ftp.vim.org/pub/vim/pc/gvim73_46.exe)

(and a few others like pyreadline, setuptools etc, but I don't believe they are relevant to the problem)

My OS is 64bit Windows 7 Enterprise SP1

I get the error doing the following in gvim:

:so C:\Python27\share\doc\ipython\examples\vim\ipy.vim
:IPythonClipboard

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<string>", line 39, in km_from_string
  File "C:\Python27\lib\site-packages\IPython\zmq\blockingkernelmanager.py", line 25, in <module>
    from .kernelmanager import (KernelManager, SubSocketChannel, HBSocketChannel
  File "C:\Python27\lib\site-packages\IPython\zmq\kernelmanager.py", line 29, in <module>
    import zmq
  File "C:\Python27\lib\site-packages\zmq\__init__.py", line 35, in <module>
    from zmq.utils import initthreads @ initialize threads
ImportError: DLL load failed: The specified module could not be found

If I run C:\Python27\python.exe I can type:

import zmq
from zmq.utils import initthreads 

without any error.

Having tried to trace things a little further, I've notied that

C:\Python27\Lib\site-packages\zmq\utils\initthreads.pyd

show an error in DependancyWalker:

MSVCR90.DLL was not found

Checking C:\Windows\SysWOW64\python27.dll in DependancyWalker shows that it
does have a successful reference to MSVCR90.DLL at the following location:

c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.DLL

C:\Python27\python.exe also has a successful reference to MSVCR90.DLL
in DependancyWalker (same value):

c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.DLL

However if I load gvim.exe in DependancyWalker, I find that it no reference
to MSVCR90.DLL at all - it simply doesn't link against it.

This leads my to believe that it is the MSVCR90.DLL dependancy that is the
problem on the machine I'm using, and that it is satisifed by python.exe
itself, and so everything works when you test it in python, but is
not present in gvim.exe, and so when the initthreads.pyd library gets
loaded, it encounters the "DLL load failed" error.

Grepping the interwebs for similar problems, I came across:

http://code.google.com/p/pyodbc/issues/detail?id=214

which looks to me (and I know very little about WOW or manifests etc) like
it might be describing roughly the same problem.

[ivanov]

I am having a similar problem to other people here. In fact I think it is more or less issue 80

I assume you meant zeromq/pyzmq#80, and tried the PATH solution @minrk suggested there, which didn't work?

I know very little about windows development, but did you try the workaround suggested in that pyodbc link you provide

[edouardp]

Yes - I was meaning issue zeromq/pyzmq#80, correct.

The path suggestion didn't seem to work for me - from what I've read about the 64bit Windows-on-Windows subsystem that allows you to run 32bit code on a 64 windows system is that is quite restrictive about DLLs and where they can live. Or I was doing something wrong - that's pretty likely as well.

As for following the instructions in the pyodbc bug report, I did this with all of the *.pyd files and now I've got gvim <-> ipython 0.12 interaction going great!

The manifest file that is used inside python27.dll is:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
    </requestedPrivileges>
  </security>
</trustInfo>
<dependency>
  <dependentAssembly>
    <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
  </dependentAssembly>
</dependency>
</assembly>

Perhaps you can figure out a way to embed that manifest during the build of the windows package? I think that would solve the problem for anyone else running 32bit python on a 64bit Windows.

[edouardp]

Looking back over the closed bug, this might also be the same as #10

[ivanov]

thanks for sticking with it, and glad you were able to figure it out.

[johndgiese]

So I downloaded the dependency walker program (it is a very nice tool), and ran it on the C:\Python27\lib\site-packages\zmq\libzmq.dll and sure enough it wasn't linked to MSVCR90.DLL

I then ran it on C:\Python27\python.exe and it was linked to MSVCR90.DLL (although oddly enough, it has a missing link to Python27.dll ... not sure what to make of this)

I then used the manifest tool, and was able to reproduce (exactly) the manifest edourdp posted above. So I think I am on the write trail. So my question now is, which pyd files do I need to run mt.exe on? And what inputsource should I use, C:\Python27\python.exe or C:\windows\syswow64\python27.dll

[johndgiese]

So i used the manifest tool on every pyd (and the single dll) in the ...\site-packages\zmq directory, and I can now run the IPython command succesfully from within gvim, furthermore it complains that it can't talk to the IPython kernel when it is not open, but it won't complain when it is open. This makes me think that it is mostly working. However, I can not send text over using . I checked the mapping in vim by using :map and it is mapped correctly... not really sure where to go from here.

[ivanov]

Ok, @johndgiese, glad you haven't given up, and it sounds like you are indeed very close. You can try another similar binding, to see if it's just Ctrl-S that doesn't seem to work. Alt-S does the same thing, but strips the leading whitespace (useful when trying to run lines that are within some function or class definition).

If that still doesn't work, try just using one of the python functions we made for sending commands to IPython like this:
:py run_command('a=42') and check in IPython for the value of a. If that doesn't work, open a new vim-ipython issue with what happens when you do that (since it's no longer related to the zmq DLLs)

best of luck!

[johndgiese]

It turns out everything was working after I used the mt.exe tool as described above. My further difficulties had to do with custom mappings in my vimrc, that were conflicting with the default vim-ipython mappings. It may be a good idea to disable recursive mappings, or to add the key to the mappings you add. See here:
http://learnvimscriptthehardway.stevelosh.com/chapters/05.html#recursion

[johndgiese]

Thanks so much for your work on this tool, it is really great from the bit I have used it so far. I will probably start playing around with the commented out debugging code at some point, as that would also be a great tool to have available.

[pag]

This hit me too. In the end I just had to run mf on libzmq.dll:

mt.exe -inputresource:C:\Python27_64\python.exe;#1 -outputresource:C:\Python27_64\Lib\site-packages\zmq\libzmq.dll;#2

This didn't work with the pyzmq I installed via easy_install, but it did with the zmq built by the excellent people at http://www.lfd.uci.edu/~gohlke/pythonlibs/

[retzzz]

This really save me. I tried to install vim-ipython on python 3.2. It spend me the hole weekend. I can't be successful without this. Thank you.

[arkottke]

I recently had this problem and solved it by using the DLLs directly from ZeroMQ (http://www.zeromq.org/intro:get-the-software), instead of from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/