Big picture is
In Windows 7, lackey installed with pip in a python3.6.1 virtualenv created with a python2.7.2 interpreter from an unpacked .tar.gz of virtualenv15.1.0 can't import the cv2 module.
Context / Environment
In Windows 7 (x64) with C:\Users\user1>C:\Python27\python.exe C:\VirtualenvTools\virtualenv-15.1.0\virtualenv.py --python=C:\VirtualenvTools\Python36\Python.exe C:\virtualenvs\virtualenv (all one line) I create a virtualenv and set its C:\virtualenvs\virtualenvname\Scripts\Python.exe file as the main interpreter for a PyDev project in Eclipse.
I also installed lackey after entering the virtualenv with activate and then the pip install lackey command # the C:\virtualenvs\virtualenvname\Scripts\ directory without any listed errors (installation worked).
The problem
When I import lackey with from lackey import * in my PyDev project, there is an ImportError from Eclipse's console.
The console's stackTrace:
Traceback (most recent call last):
File "C:\Users\user1\workspace\sikulixframework0.1\testManager.py", line 4, in <module>
from lackey import *
File "C:\virtualenvs\virtualenvname\lib\site-packages\lackey\__init__.py", line 31, in <module>
from .RegionMatching import Pattern, Region, Match, Screen, ObserveEvent
File "C:\virtualenvs\virtualenvname\lib\site-packages\lackey\RegionMatching.py", line 17, in <module>
import cv2
File "C:\virtualenvs\virtualenvname\lib\site-packages\cv2\__init__.py", line 7, in <module>
from . import cv2
ImportError: DLL load failed: Le module spécifié est introuvable.
(Le module spécifié est introuvable. = The specified module could not be found.)
When using the same interpreter (C:\virtualenvs\virtualenvname\Scripts\Python.exe) directly, if I write from lackey import * I get the same stackTrace
My resolution tries
I tried the same things (from lackey import *) outside a virtual environment and it worked. Like suggested in an answer to the stackoverflow's question 'Can't import cv2; “DLL load failed”', I downloaded the Visual C++ 2015 redistributable package but nothing of my complications changed.
I added, in the Windows PATH environment variable, the path to the original Python3.6.1 from the path\to\original\python36\python.exe in C:\Users\user1>C:\Python27\python.exe C:\VirtualenvTools\virtualenv.py --python=C:\VirtualenvTools\Python36\Python.exe C:\virtualenvs\virtualenv command for the virtualenv's creation that contained that python3.dll file and added that same python3.dll file in the C:\virtualenvs\virtualenv\Scripts directory and it worked!
Summary if you use virtualenv and an ImportError occurs (for cv2 at least)
Make sure that the path to the executable (which contains the python3.dll file in python3.6.1 at least) that is referenced by the virtualenv (after that --python= part of the creation command) is in the "PATH" Windows environment variable.
Add that same python3.dll file to the \Scripts\ directory where the virtualenv is.
The lackey project git owner(glitchassassin)'s answer helped me resolve this issue. He also states that this problem is caused by virtualenv:
Looks like this is actually also an issue in virtualenv.
On the issue of virtualenv, some people found the same solution:
[N]o need to download DLL files from untrusted random Internet sites, just copy the one from c:/Python3.5/ (or wherever you installed Python 3.5) into any directory on your %PATH%.
Related
I am having issues getting python to import the _analog_swig gnuradio module in order to run gnuradio code on a Windows 8.1 64bit machine.
Some background: I am running Python 2.7.10 (installed in C:\Python27) and have installed the latest gnuradio binary (v3.7.11.1/v1.3 64-Bit Any CPU) from here: http://www.gcndevelopment.com/gnuradio/downloads.htm. I have installed gnuradio to C:\Program Files\GNURadio-3.7 .
I can run gnuradio companion and run flowgraphs from GRC successfully (which calls "C:\Program Files\GNURadio-3.7\bin\run_gr.bat" gnuradio-companion.py).
I have added & verified the following system variables are set:
Path: C:\Program Files\GNURadio-3.7\bin
PYTHONPATH: C:\Program Files\GNURadio-3.7\lib\site-packages
GRC_BLOCKS_PATH: C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks
Now to the problem: If I run e.g. CMD and type:
python C:\test\top_block.py
I am returned the following ImportError:
File "C:\test\top_block.py", line 22, in <module>
from gnuradio import analog
File "C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\analog\__init__.py", line 33, in <module>
from analog_swig import *
File "C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\analog\analog_swig.py", line 17, in <module>
_analog_swig = swig_import_helper()
File "C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\analog\analog_swig.py", line 16, in swig_import_helper
return importlib.import_module('_analog_swig')
File "C:\Python27\lib\importlib\__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named _analog_swig
The folder content of C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\analog is as follows:
Comparing this to the folder content on a linux machine, which has a working install of gnuradio that works with python as I want it:
The difference seems to be that the folder in windows contains only a _analog_swig.pyc file, whereas the folder in linux contains a _analog_swig_.so file.
Any idea why the _analog_swig module can apparently not be imported in windows?
My plan is to be able to run gnuradio code directly from my python interpreter and being able to create compiled gnuradio executables so any help on how this could be fixed is much appreciated.
I've been struggling with this for the past few days, but I finally figured it out. I was trying to run GnuRadio Companion generated code in IDLE and also in PyCharm. I kept failing miserably with this same error. I finally figured it out:
-As Flexo says, the PYD file (_analog_swig.pyd) is actually a Windows DLL. The error makes it sound like Python is not finding that file, but that is not at all what was happening. The PYD file, being a DLL, has dependencies itself. Python is able to find _analog_swig.pyd just fine, but it could not find the DEPENDENCIES of that library.
-To verify if that's what wrong in your installation, download and use DependencyWalker (Google it) to check if your system can find the dependencies to _analog_swig.pyd.
-The fix for me was to add the GnuRadio-3.7/bin folder to my PATH environment variable. Inside that folder are a number of DLLs that the _analog_swig.pyd library needs to load. If you don't have the folder in your PATH, the module will fail to load in Python and throw the error you see above.
-I see that you verified that this folder is in your PATH, so this is apparently not the same problem, although your symptoms are exactly the same as mine. i.e. the GRC code would run just fine when you start with "run_gr.bat", but not when you run from a normal CMD window.
Hopefully that helps someone else that wants to use GNURadio Python code on Windows.
Friend,
As you mentioned, the GNU Companion calls \bin\run_gr.bat gnuradio-companion.py. That batch script does quite a bit of work on windows environment variables (try opening it in a text editor if you're curious).
In a sense, the run_gr.bat script puts together a temporary, custom python workspace for gnuradio so it can import anything it needs. It receives python scripts to run in this environment as command line arguments; hence, you can use it to run any GNU radio python code you want in your windows command prompt. Generally, you would call
<gnuradio_install_path>\bin\run_gr.bat <gnu_radio_code>.py
To test your import, you can try
# test.py
from gnuradio import analog
try calling the following from the command prompt, in the test.py directory:
<gnuradio_install_path>\bin\run_gr.bat test.py
I have the same problem that was discussed here, but I haven't credit to comment an answer so I start new question.
I have in PATH way to libpq.dll (C:\PostgreSql\lib) but it doesn't solve this problem.
Using Python 2.7.9 32-bit, PostgreSQL 8.4, Win 8
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
import pg
File "C:\Python27\lib\site-packages\pg.py", line 21, in <module>
from _pg import *
ImportError: DLL load failed: The specified module could not be found.
I was also facing the same issue on Win 8. First time I had installed PostgreSQL in "C:\Program Files" and also set environment PATH to point to PostgreSQL folder. I was suspecting permission issue for "C:\Program Files" folder.
I was able to fix this issue by following the steps as mentioned below.
Uninstalled PostgreSQL
Re-installed PostgreSQL in "C:\PostgreSQL"
Note that I have not installed PostgreSQL into "C:\Program Files" folder this time
Set the environment PATH C:\PostgreSQL\9.4;C:\PostgreSQL\9.4\bin
Also ensure that _pg.pyd exist in C:\Python27\Lib\site-packages
I got the same error on Win10 with Python 3.5 and Python 3.8, both are 64bit, and Postresql 12, also 64bit. DLL locations "c:\Program Files\PostgreSQL\12\bin" and "c:\Program Files\PostgreSQL\psqlODBC\bin" were added to the PATH but it caused another error:
"from _pg import * ImportError: DLL load failed: The operating system cannot run %1."
Then I've checked what is going on with Process Monitor from Sysinternals and found that libpg.dll was looking for other DLLs. Finally, the following files:
libpq.dll
libssl-1_1-x64.dll
libcrypto-1_1-x64.dll
were copied from "c:\Program Files\PostgreSQL\12\bin" folder to:
"c:\Users...\AppData\Local\Programs\Python\Python35"
"c:\Users...\AppData\Local\Programs\Python\Python38"
folders and now "import pg" works fine in both versions of Python.
I faced just the same issue; just to try my chance before doing what you say, I changed the PATH environment variable: I directly specified the whole directory path of libpq.dll OF THE ODBC DRIVER OF PostgreSQL (there are other "libpqdll"s as well in other relevant directories) which takes place in my Windows10 here: C:\Program Files\PostgreSQL\psqlODBC\bin .. and the problem is solved.. before, my PATH specification was C:\Program Files\PostgreSQL and I think the driver looked for the dll files directly here and either 1) when couldnt find directly in this specific diretory (by disregarding the subdirectories), 2) or came cross other "libpq.dll"s which didnt work for the driver, it gave the error message.. so here I come to the conclusion that it looks for the dll file OF THE ODBC DRIVER in PATH env.varible, so I needed to specify in the PATH environment variable directly the directory of the PostgreSQL's ODBC driver I used, psqlODBC .. for future needs I wanted to write those details:)
I am using Anaconda on OS X Mavericks. When I try loading cv2 I get an import error (see below). Do you know how to fix this?
>>import cv2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen(/usr/local/Cellar/opencv/2.4.8.2/lib/python2.7/site-packages/cv2.so,
2): Library not loaded: /usr/local/lib/libpng15.15.dylib
Referenced from: /usr/local/Cellar/opencv/2.4.8.2/lib/libopencv_highgui.2.4.dylib
Reason: image not found
I am not sure it's relevant, but in /usr/local/lib/ I have libpng16.16.dylib instead of libpng15.15.dylib.
This is the solution I found:
comment the PYTHONPATH environment in ~/.bash_profile, as suggested by #asmeurer
install opencv using https://binstar.org/jjhelmus/opencv
As suggested in this issue, I fixed this problem by simply executing
conda update hdf5
you could also just add it to your PYTHONPATH. here's how:
you should be able to get it to load through one of the other (non anaconda) python executables. mine were located at:
/usr/bin/python (default system python) and /usr/local/bin/python (brew)
call the python executable using the full path
once you successfully import cv2 run: cv2.__file__
this will give you the file's path which you can then take (full directory path not including filename) and add as the first argument to your PYTHONPATH defined in ~/.bash_profile
after changing the .bash_profile don't forget to run
source ~/.bash_profile to make the changes effective
fire up anaconda python and it should now find cv2
I have a code in python that I have been working on and it builds and runs very well on my pc (Windows). I had to run the same code on my other machine which runs ubuntu,so I had to install all the packages on prior to runing the code. The problem is I ran into this error which I couldn't figure out. The error is triggered by one of the installed packages.
from qalsadi import analex
File "/usr/local/lib/python2.7/dist-packages/qalsadi/analex.py", line 14, in <module>
import pyarabic.araby as araby # basic arabic text functions
File "/usr/local/lib/python2.7/dist-packages/pyarabic/araby.py", line 28, in <module>
from stack import *
ImportError: No module named stack
I used the following command, "sudo pip install pyarabic", to install it. However, still the file stack.py doesn't exist among it's files. I searched in the folder /usr/local/lib/python2.7/dist-packages/pyarabic. The folder contains the following: araby.py and init.py and the coresponding pyc files only. I'v insalled and uninstalled it a number of times using "pip" but still the file is not there.
Check your pyarabic folder. Usually it's in Python27\Lib\site-packages\pyarabic.
There, there should be stack.py. If it doesn't exists, re-download pyarabic and then reinstall it.
After installation of pyarabic import STACK in this manner:
from pyarabic.stack import Stack
for window users
open cmd prompt and type the following to install the stack variable to python 3.x-
pip install pyarabic
To install and run with this code-
from pyarabic.stack import Stack
It seems like stack is not part of the Python Package Index so most probably it is a script you installed manually. The problem can be that the folder containing stack.py is not on your PYTHONPATH.
Open a terminal (Ctrl+ Alt + t) and edit the .bashrc file:
sudo gedit ~/.bashrc
Add the following line:
export PYTHONPATH=$PYTHONPATH:/path/to/the/folder/of/your/module
where you should substitute the part after the : to the full path to the directory
where stack.py can be found.
I hope this helps.
Compiled the libjpeg v8, PIL 1.1.7 and and import for _imaging works on the system Python, but spouts this error inside the virtualenv:
libjpeg.so.8: cannot open shared object file: No such file or directory
here is the error run with a python -v interpreter inside the virtualenv
>>> import _imaging
dlopen("/home/ygamretuta/dev/py/django/lib/python2.6/site-packages/PIL/_imaging.so", 2);
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: libjpeg.so.8: cannot open shared object file: No such file or directory
and here are the paths:
/home/ygamretuta/dev/py/django/lib/python2.6/site-packages/distribute-0.6.14-py2.6.egg
/home/ygamretuta/dev/py/django/lib/python2.6/site-packages/pip-0.8.1-py2.6.egg
/home/ygamretuta/dev/py/django/lib/python2.6
/home/ygamretuta/dev/py/django/lib/python2.6/plat-linux2
/home/ygamretuta/dev/py/django/lib/python2.6/lib-tk
/home/ygamretuta/dev/py/django/lib/python2.6/lib-old
/home/ygamretuta/dev/py/django/lib/python2.6/lib-dynload
/usr/lib/python2.6
/usr/lib/python2.6/plat-linux2
/usr/lib/python2.6/lib-tk
/home/ygamretuta/dev/py/django/lib/python2.6/site-packages
/home/ygamretuta/dev/py/django/lib/python2.6/site-packages/PIL
I am using Ubuntu 10.10 and this is the uname-a output:
Linux ygam-desktop 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:40:58 UTC 2011 i686 GNU/Linux
I am using Python 2.6
I followed the following guides already:
http://appelfreelance.com/2010/06/libjpeg-pil-snow-leopard-python2-6-_jpeg_resync_to_restart/
http://www.jooncode.com/2010/12/02/python-pil-jpeg-resync-restart-error-imaging-module-solve/
http://djangodays.com/2008/09/03/django-imagefield-validation-error-caused-by-incorrect-pil-installation-on-mac/
See an explanation here: Why can't Python find shared objects that are in directories in sys.path?
A quick fix is to add the directory that contains libjpeg.so.8 to your /etc/ld.so.conf file, and then run ldconfig
Also if you are doing local Python installations you can also control dynamic linking on the session level using LD_LIBRARY_PATH environment variable::
export LD_LIBRARY_PATH=/srv/plone/python/python-2.6/lib
python
import _imaging
...
This way you cannot break your OS itself, even accidentally. (It happens: http://opensourcehacker.com/2011/08/31/zend-server-installation-potentially-kills-your-ssh/)
Compiling the library from source works too: http://www.ijg.org/files/
Make sure to use jpegsrc.v8.tar.gz if you're on a Unix like system though. jpegsr8.zip appears to be the MS version, and throws all the standard formatting issues while building.
maybe just install libjpeg
conda install -c conda-forge libjpeg-turbo