Permission denied on dl.open() with ipython but not with python

Question

My initial goal is to open a dll file on Cygwin using ctypes. However I found some issues with it. I dug up to sys.dl which returns an unk

Answer 1

• Perhaps Python executable and IPython kernel use different manifest files which define loading policy?

• Try appending the DLL path to sys.path in both cases.

• Check admin rights (UAC) in both cases.

• Use dependency walker to figure out dependencies of this DLL. Maybe the problem comes from dependencies?

• Possibly your machine has multiple copies of this DLL?

• Finally you can use Process Explorer to see the list of DLLs loaded in both cases and see any differences.

I'm working on a very similar issue:

ipython notebook & script difference - loading DLLs

Answer 2

Two ideas:

1) in the next cell, type %pdb, and then interactively "print self._name" to see what it is.

2) Use a full path to cdll.LoadLibrary("foo.dll") to see if that works.

Once you know what the issue is, then you can decide whose bug it is, and report it (could be a ctypes issue, but probably ipython)

Answer 3

More ideas:

• Check that the user accessing the DLL is the same. You do that like this:

  import getpass

  print(getpass.getuser())

• Check what's the current process actually doing. I haven't used cygwin but in the linux shell the executable strace should show you this. Usage: get the PID of your current process: import os; os.getpid() After this, you can use (from outside the python/ipython console the command strace -p <the pid> -e file. After this setup, you can try to load your DLL.

Remarks: the -e file flag should be written exactly like that. The word file tells strace to report all file operations that the process makes. If no differences occur when running on python/ ipython, you can try dropping the -e file flag. Then you will see all system calls that the process makes. I haven't worked on windows like that, so this might not work at all there, but on linux at least, this should report to you everything that the process did. You could see there at least all the files that got opened, but more interesting things could be found there as well. If the outputs are identical, then the problem can be debugged further in python/ ipython. This would require basically what @Doug Blank suggested, but I'd also recommend investigating every name (variable) that gets touched. The self, _dlopen and mode names also sound like they might contain useful information.

Otherwise, do a dir(self) and dir(_dlopen) to see what other properties you could find there that might have gotten modified by IPYthon.

Try these first, and after that we can help you dig further.