I am unable to use virt-manager, and I think it's because of where my python is located. When I run the virt-manager command I get: No module named libvirt even though I have libvirt installed. When I run /usr/bin/python /usr/share/virt-manager/virt-manager.py it works fine. The output from which python is /usr/local/bin/python. I've tried creating a ~/.bash_profile that contains this: export PYTHONPATH=$PYTHONPATH:/usr/bin/python but am still having the same problem.
I'm sure there is a simple solution to this?
You can make a symbolic link, example:
sudo mv /usr/local/bin/python python-old # example name
sudo ln -s /usr/bin/python /usr/local/bin/python
To be clear, the PYTHONPATH environmental variable sets where your python session looks for modules. It doesn't set the location of your python interpreter, which I think is what you want to do.
What you need to do is add and alias for the python interpreter that you do want to use to your bash_profile. Something like this:
alias python='/usr/bin/python'
Shell/OS: Cygwin/Windows 7
Source code: Source code
Required package: Required package
Installation:
I downloaded the following Source code on windows. I moved the requited package to models and I installed the package by using the following command: python setup.py install
Test:
by using Cygwin I wanted to test the package by typing: ./run-test:
#!/cygdrive/c/Python27/python
rm -rf temp
ocropus-nlbin tests/testpage.png -o temp
ocropus-gpageseg 'temp/????.bin.png'
ocropus-rpred -n 'temp/????/??????.bin.png'
ocropus-hocr 'temp/????.bin.png' -o temp.html
ocropus-visualize-results temp
ocropus-gtedit html temp/????/??????.bin.png -o temp-correction.html
echo "to see recognition results, type: firefox temp.html"
echo "to see correction page, type: firefox temp-correction.html"
echo "to see details on the recognition process, type: firefox temp/index.html"
Error:
File "./run-test", line 3
rm -rf temp
^
SyntaxError: invalid syntax
What caused this error?
The #! line says this is a Python script. So why would a shell command be acceptable syntactically?
Try #!/bin/sh/ instead.
I have just installed python 2.7 using macports as:
sudo port install py27-numpy py27-scipy py27-matplotlib py27-ipython +notebook py27-pandas py27-sympy py27-nose
during the process it found some issues, mainly broken files related with py25-haslib that I managed to fix. Now it seems eveything is ok. I tested a few programs and they run as expected. Currently, I have two versions of python: 2.5 (Default, from when I worked in my former institution) and 2.7 (just installed):
which python
/usr/stsci/pyssg/Python-2.5.1/bin/python
which python2.7
/opt/local/bin/python2.7
The next move would be set the new python version 2.7 as default:
sudo port select --set python python27
sudo port select --set ipython ipython27
My question is: is there a way to go back to 2.5 in case something goes wrong?
I know a priori, nothing has to go wrong. But I have a few data reduction and analysis routines that work perfectly with the 2.5 version and I want to make sure I don´t mess up before setting the default.
if you want to revert, you can modify your .bash_profile or other login shell initialization to fix $PATH to not add "/Library/Frameworks/Python.framework/Versions/2.5/bin" to $PATH and/or to not have /usr/local/bin appear before /usr/bin on $PATH.
If you want to permanently remove the python.org installed version,
paste the following lines up to and including the chmod into a posix-
compatible shell:
tmpfile=/tmp/generate_file_list
cat <<"NOEXPAND" > "${tmpfile}"
#!/bin/sh
version="${1:-"2.5"}"
file -h /usr/local/bin/* | grep \
"symbolic link to ../../../Library/Frameworks/Python.framework/"\
"Versions/${version}" | cut -d : -f 1
echo "/Library/Frameworks/Python.framework/Versions/${version}"
echo "/Applications/Python ${version}"
set -- Applications Documentation Framework ProfileChanges \
SystemFixes UnixTools
for package do
echo "/Library/Receipts/Python${package}-${version}.pkg"
done
NOEXPAND
chmod ug+x ${tmpfile}
...excripted from troubleshooting question on python website
It took the equivalent of a 1/2 day for me to figure this out, so I want to share the Quickfix Engine compile problem I encountered and the solution.
I didn't get a reply from the "Quickfix Engine" help resources pointed to here:
"http://quickfixengine.org/help"... thus another reason I am providing this.
Environment: Fedora 18 -and- CentOS6 (64bit).
After successfully compiling quickfix with Python support (i.e. configure [opts]; make; make install), I got the following python import exception indicating that the python module, "_quickfix", could not be found:
==============================================
user$ python -c "import quickfix"
Traceback (most recent call last):
File " ", line 1, in
File "/home/user/APPS.d/ENTHOUGHT-PYTHON-IDE.d/x86_64.d/latest/lib/python2.7/site-packages/quickfix.py", line 7, in
import _quickfix
ImportError: No module named _quickfix
==============================================
The problem appears to be in the install script invoked by "make install".
The python interpreter is saying that the "_quickfix" module does not exit. As can be seen from the list of files install by "make install" below, there is no "_quickfix.py" file, but there is a reference to a "_quickfix.so" file and a "_quickfix.dylib" file:
/home/user/.local/lib/python2.7/site-packages/_quickfix.dylib -> /home/user/APPS.d/QUICKFIX.d/latest/lib/python/_quickfix.dylib
/home/user/.local/lib/python2.7/site-packages/_quickfix.so -> /home/user/APPS.d/QUICKFIX.d/latest/lib/python/_quickfix.so
/home/user/.local/lib/python2.7/site-packages/quickfix40.py
/home/user/.local/lib/python2.7/site-packages/quickfix41.py
/home/user/.local/lib/python2.7/site-packages/quickfix42.py
/home/user/.local/lib/python2.7/site-packages/quickfix42.pyc
/home/user/.local/lib/python2.7/site-packages/quickfix43.py
/home/user/.local/lib/python2.7/site-packages/quickfix44.py
/home/user/.local/lib/python2.7/site-packages/quickfix50.py
/home/user/.local/lib/python2.7/site-packages/quickfix50sp1.py
/home/user/.local/lib/python2.7/site-packages/quickfix50sp2.py
/home/user/.local/lib/python2.7/site-packages/quickfix.py
/home/user/.local/lib/python2.7/site-packages/quickfix.pyc
/home/user/.local/lib/python2.7/site-packages/quickfixt11.py
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix.la
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix_python.la
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix_python.so.10.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix_python.so.10 -> libquickfix_python.so.10.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix_python.so -> libquickfix_python.so.10.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix.so.14.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix.so.14 -> libquickfix.so.14.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix.so -> libquickfix.so.14.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/pkgconfig/quickfix.pc
SOLUTION:
The problem is that the first two entries above, which are symbolic links, are broken.
First, the destination directory is incorrect:
/home/user/APPS.d/QUICKFIX.d/latest/lib/python/...
should actually be:
/home/user/APPS.d/QUICKFIX.d/latest/lib/...
So we fix that first:
user$ cd /home/user/.local/lib/python2.7/site-packages
user$ rm _quickfix.so _quickfix.dylib
user$ ln -s /home/user/APPS.d/QUICKFIX.d/latest/lib/_quickfix.so _quickfix.so
user$ ln -s /home/user/APPS.d/QUICKFIX.d/latest/lib/_quickfix.dylib _quickfix.dylib
Next, with destination directory location corrected, the symbolic links are still broken; this time because the file names that they point to in that (just corrected) destination directory don't exist (i.e. "_quickfix.so" and "_quickfix.dylib" don't exist).
After playing around a little, I got things to work by creating those missing files like so:
user$ cd /home/user/APPS.d/QUICKFIX.d/latest/lib
user$ ln -s libquickfix_python.so _quickfix.so
user$ ln -s <???> _quickfix.dylib # Actually I didn't create this one yet. It's not yet clear to me what it should point to. I Will update this post later.
-
Note: Because I compiled QuickFix so that it does not install to the traditional "/usr/local/" directory structure, I had to append my "LD_LIBRARY_PATH" to include: "/home/user/APPS.d/QUICKFIX.d/latest/lib"
With minimal testing, things seem to work now (or at least in the right direction):
user$ python -c "import quickfix"; echo ${?}
0
user$ python -c "import quickfix42"; echo ${?}
0
When I figure out what the second link should be (if it is necessary), or if I should encounter any run-time errors with the corrections I implemented, I'll update/edit this post.
I hope this helps someone.
Noel
Had the same problem in Ubuntu 13.04. configured with python support and used the default destination (/usr/local/...). After successful compilation then worked out a similar solution with the following steps;
Create missing files/symlinks;
cd /usr/local/lib
sudo ln -s libquickfix_python.so _quickfix.so
sudo ln -s _quickfix.so _quickfix.dylib
Change/update existing symlinks to new location:
cd /usr/lib/python2.7/dist-packages/
sudo ln -s /usr/local/lib/_quickfix.so _quickfix.so
sudo ln -s /usr/local/lib/_quickfix.so _quickfix.dylib
Add new library path
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH${LD_LIBRARY_PATH:+:}/usr/local/lib
You do not need to create multiple symlinks - you only need to remove the bad symlinks and create one new symlink for _quickfix.so for everything to work:
rm /usr/local/lib/python2.7/site-packages/_quickfix.dylib
rm /usr/local/lib/python2.7/site-packages/_quickfix.so
ln -s /usr/local/lib/libquickfix_python.dylib /usr/local/lib/python2.7/site-packages/_quickfix.so
This is on OS X. For Linux you will need to use the following (as the dylib extension is OS X specific)
ln -s /usr/local/lib/libquickfix_python.so /usr/local/lib/python2.7/site-packages/_quickfix.so
I am installing Python 2.7 on CentOS 5. I built and installed Python as follows
./configure --enable-shared --prefix=/usr/local
make
make install
When I try to run /usr/local/bin/python, I get this error message
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
When I run ldd on /usr/local/bin/python, I get
ldd /usr/local/bin/python
libpython2.7.so.1.0 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030e9a00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000030e9200000)
libutil.so.1 => /lib64/libutil.so.1 (0x00000030fa200000)
libm.so.6 => /lib64/libm.so.6 (0x00000030e9600000)
libc.so.6 => /lib64/libc.so.6 (0x00000030e8e00000)
/lib64/ld-linux-x86-64.so.2 (0x00000030e8a00000)
How do I tell Python where to find libpython?
Try the following:
LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python
Replace /usr/local/lib with the folder where you have installed libpython2.7.so.1.0 if it is not in /usr/local/lib.
If this works and you want to make the changes permanent, you have two options:
Add export LD_LIBRARY_PATH=/usr/local/lib to your .profile in your home directory (this works only if you are using a shell which loads this file when a new shell instance is started). This setting will affect your user only.
Add /usr/local/lib to /etc/ld.so.conf and run ldconfig. This is a system-wide setting of course.
Putting on my gravedigger hat...
The best way I've found to address this is at compile time. Since you're the one setting prefix anyway might as well tell the executable explicitly where to find its shared libraries. Unlike OpenSSL and other software packages, Python doesn't give you nice configure directives to handle alternate library paths (not everyone is root you know...) In the simplest case all you need is the following:
./configure --enable-shared \
--prefix=/usr/local \
LDFLAGS="-Wl,--rpath=/usr/local/lib"
Or if you prefer the non-linux version:
./configure --enable-shared \
--prefix=/usr/local \
LDFLAGS="-R/usr/local/lib"
The "rpath" flag tells python it has runtime libraries it needs in that particular path. You can take this idea further to handle dependencies installed to a different location than the standard system locations. For example, on my systems since I don't have root access and need to make almost completely self-contained Python installs, my configure line looks like this:
./configure --enable-shared \
--with-system-ffi \
--with-system-expat \
--enable-unicode=ucs4 \
--prefix=/apps/python-${PYTHON_VERSION} \
LDFLAGS="-L/apps/python-${PYTHON_VERSION}/extlib/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/extlib/lib" \
CPPFLAGS="-I/apps/python-${PYTHON_VERSION}/extlib/include"
In this case I am compiling the libraries that python uses (like ffi, readline, etc) into an extlib directory within the python directory tree itself. This way I can tar the python-${PYTHON_VERSION} directory and land it anywhere and it will "work" (provided you don't run into libc or libm conflicts). This also helps when trying to run multiple versions of Python on the same box, as you don't need to keep changing your LD_LIBRARY_PATH or worry about picking up the wrong version of the Python library.
Edit: Forgot to mention, the compile will complain if you don't set the PYTHONPATH environment variable to what you use as your prefix and fail to compile some modules, e.g., to extend the above example, set the PYTHONPATH to the prefix used in the above example with export PYTHONPATH=/apps/python-${PYTHON_VERSION}...
I had the same problem and I solved it this way:
If you know where libpython resides at, I supposed it would be /usr/local/lib/libpython2.7.so.1.0 in your case, you can just create a symbolic link to it:
sudo ln -s /usr/local/lib/libpython2.7.so.1.0 /usr/lib/libpython2.7.so.1.0
Then try running ldd again and see if it worked.
I installed Python 3.5 by Software Collections on CentOS 7 minimal. It all worked fine on its own, but I saw the shared library error mentioned in this question when I tried running a simple CGI script:
tail /var/log/httpd/error_log
AH01215: /opt/rh/rh-python35/root/usr/bin/python: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
I wanted a systemwide permanent solution that works for all users, so that excluded adding export statements to .profile or .bashrc files. There is a one-line solution, based on the Red Hat solutions page. Thanks for the comment that points it out:
echo 'source scl_source enable rh-python35' | sudo tee --append /etc/profile.d/python35.sh
After a restart, it's all good on the shell, but sometimes my web server still complains. There's another approach that always worked for both the shell and the server, and is more generic. I saw the solution here and then realized it's actually mentioned in one of the answers here as well! Anyway, on CentOS 7, these are the steps:
vim /etc/ld.so.conf
Which on my machine just had:
include ld.so.conf.d/*.conf
So I created a new file:
vim /etc/ld.so.conf.d/rh-python35.conf
And added:
/opt/rh/rh-python35/root/usr/lib64/
And to manually rebuild the cache:
sudo ldconfig
That's it, scripts work fine!
This was a temporary solution, which didn't work across reboots:
sudo ldconfig /opt/rh/rh-python35/root/usr/lib64/ -v
The -v (verbose) option was just to see what was going on. I saw that it did:
/opt/rh/rh-python35/root/usr/lib64:
libpython3.so.rh-python35 -> libpython3.so.rh-python35
libpython3.5m.so.rh-python35-1.0 -> libpython3.5m.so.rh-python35-1.0
This particular error went away. Incidentally, I had to chown the user to apache to get rid of a permission error after that.
Note that I used find to locate the directory for the library. You could also do:
sudo yum install mlocate
sudo updatedb
locate libpython3.5m.so.rh-python35-1.0
Which on my VM returns:
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0
Which is the path I need to give to ldconfig, as shown above.
This worked for me...
$ sudo apt-get install python2.7-dev
On Solaris 11
Use LD_LIBRARY_PATH_64 to resolve symlink to python libs.
In my case for python3.6 LD_LIBRARY_PATH didn't work but LD_LIBRARY_PATH_64 did.
Hope this helps.
Regards
This answer would be helpful to those who have limited auth access on the server.
I had a similar problem for python3.5 in HostGator's shared hosting. Python3.5 had to be enabled every single damn time after login. Here are my 10 steps for resolution:
Enable the python through scl script python_enable_3.5 or scl enable rh-python35 bash.
Verify that it's enabled by executing python3.5 --version. This should give you your python version.
Execute which python3.5 to get its path. In my case, it was /opt/rh/rh-python35/root/usr/bin/python3.5. You can use this path get the version again (just to verify that this path is working for you.)
Awesome, now please exit out of current shell by scl.
Now, lets get the version again through this complete python3.5 path /opt/rh/rh-python35/root/usr/bin/python3.5 --version.
It won't give you the version but an error. In my case, it was
/opt/rh/rh-python35/root/usr/bin/python3.5: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
As mentioned in Tamas' answer, we gotta find that so file. locate doesn't work in shared hosting and you can't install that too.
Use the following command to find where that file is located:
find /opt/rh/rh-python35 -name "libpython3.5m.so.rh-python35-1.0"
Above command would print the complete path (second line) of the file once located. In my case, output was
find: `/opt/rh/rh-python35/root/root': Permission denied
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0
Here is the complete command for the python3.5 to work in such shared hosting which would give the version,
LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5 --version
Finally, for shorthand, append the following alias in your ~/.bashrc
alias python351='LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5'
For verification, reload the .bashrc by source ~/.bashrc and execute python351 --version.
Well, there you go, now whenever you login again, you have got python351 to welcome you.
This is not just limited to python3.5, but can be helpful in case of other scl installed softwares.
I installed using the command:
./configure --prefix=/usr \
--enable-shared \
--with-system-expat \
--with-system-ffi \
--enable-unicode=ucs4 &&
make
Now, as the root user:
make install &&
chmod -v 755 /usr/lib/libpython2.7.so.1.0
Then I tried to execute python and got the error:
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
Then, I logged out from root user and again tried to execute the Python and it worked successfully.
All it needs is the installation of libpython [3 or 2] dev files installation.
just install python-lib. (python27-lib). It will install libpython2.7.so1.0. We don't require to manually set anything.