1

Currently, I am using Python 3.4 out of the Anaconda Suite. I have a file called "libPiCam.dll" within my working directory and I am trying to load it in this fashion:

from ctypes import cdll

def load(x):
    """Loads DLL library where argument is location of library"""
    x = cdll.LoadLibrary(x)
    return x

lib = load("PiCamLib")

But when doing that, I get this tracer back

Traceback (most recent call last):

  File "<ipython-input-27-8d86fac88101>", line 1, in <module>
    runfile('C:/Users/User/Documents/Python Scripts/PicamCode/PixisTest.py', wdir='C:/Users/User/Documents/Python Scripts/PicamCode')

  File "C:\Users\User\Anaconda3\lib\site-packages\spyderlib\widgets\externalshell\sitecustomize.py", line 685, in runfile
    execfile(filename, namespace)

  File "C:\Users\User\Anaconda3\lib\site-packages\spyderlib\widgets\externalshell\sitecustomize.py", line 85, in execfile
    exec(compile(open(filename, 'rb').read(), filename, 'exec'), namespace)

  File "C:/Users/User/Documents/Python Scripts/PicamCode/PixisTest.py", line 49, in <module>
    piFunction = load(piFunctionLib)

  File "C:/Users/User/Documents/Python Scripts/PicamCode/PixisTest.py", line 32, in load
    x = cdll.LoadLibrary(x)

  File "C:\Users\User\Anaconda3\lib\ctypes\__init__.py", line 429, in LoadLibrary
    return self._dlltype(name)

  File "C:\Users\User\Anaconda3\lib\ctypes\__init__.py", line 351, in __init__
    self._handle = _dlopen(self._name, mode)

OSError: [WinError 193] %1 is not a valid Win32 application

What confuses me the most is that I have a file called "PiCam.dll" and load it in this fashion:

picamLibrary = 'picam'
picam = cdll.LoadLibrary(picamLibrary)

And loads using th eLoad method above. This works without error. I tried shaping my call to load libPiCam to be the same way, but I get the same error. As background, I created and compiled the "libPiCam.dll" file from a C++ file in order to wrap it, allowing me to call C++ functions from Python (I followed Calling C/C++ from python?).

So, what do I do?

Community
  • 1
  • 1
philipv
  • 31
  • 1
  • 7
  • 2
    `.so` shared libraries are specific to unix. On windows you have to compile to a `dll`. – cel Oct 30 '15 at 04:52
  • I already tried that, as I mentioned above – philipv Oct 30 '15 at 15:14
  • you may want to edit and update your question. The first part with the `.so` file makes no sense as I tried to point out in my previous comment. – cel Oct 30 '15 at 15:16
  • Done. Still have any idea on how to fix this? I get the same traceback. – philipv Oct 30 '15 at 15:32
  • I think this can occur when the bitness of the dll and the bitness of python do not match. E.g. 64bit python vs. 32bit library. – cel Oct 30 '15 at 15:59
  • Get `depends.exe` from dependencywalker.com. This is a tool that allows you to analyze a DLL (or any Windows module) concerning its type, exports import etc. Opening the DLL there might give you a hint where to proceed. – Ulrich Eckhardt Oct 30 '15 at 16:46

1 Answers1

1

I notice the naming isn't quite consistent: issue with libPiCam.dll vs "PiCamLib" doesn't work, while PiCam.dll vs "picam" does. Is it a an issue with case? Have you tried "libpicam"?

Otherwise, I wouldn't be surprised with it being an issue with the Anaconda distribution itself. I've had several issues that turned out to be bugs that occur when Anaconda interacts with windows. Ie. the c++ compiler not working properly, not being able to import pywin32 unless I run the .py script with IPython for some reason, etc.

Ogaday
  • 469
  • 3
  • 13