Python 2.7 and MySQLDB: Image not found (OSX) - python

I've just installed MySQL on my 10.10.1 MAC, and I'm trying to link it to Python. However I get this error when I'm trying to import the package.
import MySQLdb as mdb
File "build/bdist.macosx-10.5-x86_64/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.macosx-10.5-x86_64/egg/_mysql.py", line 7, in <module>
File "build/bdist.macosx-10.5-x86_64/egg/_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/ME/.python-eggs/MySQL_python-1.2.5-py2.7-macosx-10.5-x86_64.egg-tmp/_mysql.so, 2): Library not loaded: libssl.1.0.0.dylib
Referenced from: /Users/ME/.python-eggs/MySQL_python-1.2.5-py2.7-macosx-10.5-x86_64.egg-tmp/_mysql.so
Reason: image not found
[Finished in 0.2s with exit code 1]
I have no idea what "Image not found" means, or how to solve this.
MySQL is connected to the server in the background, and I installed the package through the terminal window using: easy_install MySQL-python
Any suggestions on where I went wrong?

Check where your _mysql.so is linking to:
otool -L /Library/Python/2.7/site-packages/_mysql.so
In my case I built the mysql source in /tmp/ and once
tmp cleaned up my dylib went away. I never re-linked to a
reliable location like /Applications/MAMP/Library/lib where
my mysql libraries live (because I copied them here after the build).
So I went back and rebuilt everything and made sure to run the command to
update the package link to the correct dylib:
sudo install_name_tool -change <temp file location>/mysql-5.5.29/libmysql/libmysqlclient.18.dylib /Applications/MAMP/Library//lib/libmysqlclient.18.dylib /Library/Python/2.7/site-packages/_mysql.so
I followed the setup found here:
http://dreamconception.com/tech/how-to-install-mysqldb-mysql-python-on-mamp/
NOTE: That I didn't need to do the step regarding changing the configure.cmake
file. When I looked at the configure.cmake file it made sense to me so I ran
it as-is and it worked.
Also note your libmysqlclient.<num>.dylib might be something different so
do a find . -name "libmysqlclient.*.dylib" to get the right one
Now re-run the otool command and see that the linking was updated.
References (and other solutions):
Python import MySQLdb error - Mac 10.6
http://dreamconception.com/tech/how-to-install-mysqldb-mysql-python-on-mamp/

The solution to the problem can be found in this link Python: MySQLdb and "Library not loaded: libmysqlclient.16.dylib"
_mysql.so refers to libmysqlclient.16.dylib. That is, the shared library that serves as the bridge between Python and the MySQL client library, _mysql.so, refers to the dynamic library for the MySQL client library, and that library cannot be loaded for some reason.
Questions you need to answer:
Is there a libmysqlclient.16.dylib anywhere on your system? If not, you need to install the MySQL client software.
If so, is the directory containing that library in your DYLD_LIBRARY_PATH setting? If not, try adding it.
If so, you'll have to ensure that the libmysqlclient.16.dylib file is not corrupt. My copy, installed in /opt/local/lib/mysql5/mysql/libmysqlclient.16.dylib, courtesy of MacPorts, has MD5 signature c79ee91af08057dfc269ee212915801a and is 1,462,376 bytes in size. What does your copy look like?

Related

Library not loaded: /usr/local/opt/mysql/lib/libmysqlclient.21.dylib and Reason image not found

Traceback (most recent call last):
File "/Applications/MAMP/htdocs/Minor Project/xyz.py", line 5, in <module>
import config
File "/Applications/MAMP/htdocs/Minor Project/config.py", line 5, in <module>
import MySQLdb
File "/Users/brijeshlakkad/Library/Python/2.7/lib/python/site-packages/MySQLdb/__init__.py", line 19, in <module>
import _mysql
ImportError: dlopen(/Users/brijeshlakkad/Library/Python/2.7/lib/python/site-packages/_mysql.so, 2): Library not loaded: /usr/local/opt/mysql/lib/libmysqlclient.21.dylib
Referenced from: /Users/brijeshlakkad/Library/Python/2.7/lib/python/site-packages/_mysql.so
**Reason: image not found**
When i install mysql using "brew install mysql", file will be executed. And when i executed brew install mysql, there are two different mysql both running separately. I executed this file, then al data are being stored in local mysql different from phpmyadmin mysql.
Your problem, in a nutshell, is that you're trying to use the ancient mysql-python library, aka MySQLdb. That library was abandoned around the MySQL 5.1 days, so it doesn't support MySQL 6 and later, and you presumably have MySQL 8.0, so the shared library it's looking for doesn't exist, hence the image not found error.
Homebrew does include a mysql#5.5 package, which I think has a dylib with the right name, which might be old enough to work with mysql-python, if you really want to go that way, but it isn't going to be supported. Or you can download MySQL 5.0 or 5.1 source and build it yourself (there are no Mac binaries of anything older than 5.6 that will run on a current macOS), and that will definitely work.
But a better solution is to use a library that's still maintained. Unfortunately, there are many choices out there, but I get the impression that most people use one of the three big ones:
mysqlclient is a fork of mysql-python, which binds to current versions of the C libraries (brew install mysql or download the installer from the MySQL/Oracle website).
PyMySQL is a rewrite in pure Python, which doesn't even need C libraries.
MySQL Connector/Python is a new implementation written from scratch by MySQL/Oracle. (You probably want the Oracle installer with this one.)
PyMySQL is a much better drop-in replacement than mysqlclient, and it plays nice with everything else in the universe, and it's well-written code that's easy to debug if you have a problem… but it can be pretty slow. And unless you've got a whole mess of existing code to maintain, you usually don't need a perfect drop-in replacement, just something with a pretty-close connect call and support for all of DB-API 2, and mysqlclient covers that.

Django can't import cx_Oracle on OS X though python can

I'm having a very strange issue that I can't quite figure out and hope you all can. Following the steps at this link, I've installed the Oracle instant client and cx_Oracle, and I can import cx_Oracle in Python no problem. I've done all of this in a virtualenv.
The issue is when I try
./manage.py runserver
I get
raise ImproperlyConfigured("Error loading cx_Oracle module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading cx_Oracle module:
dlopen(/Users/shawn/Virtual/Django18/lib/python2.7/site-packages/cx_Oracle.so,
2): Library not loaded: /ade/b/3071542110/oracle/rdbms/lib/libclntsh.dylib.11.1
Referenced from: /Users/shawn/Virtual/Django18/lib/python2.7/site-packages/cx_Oracle.so
Reason: image not found
Of course, that's exactly where the cx_Oracle.so file exists.
So I searched and found this SO question, but running the Ruby script actually breaks my cx_Oracle import in python, and doesn't resolve the django issue. Instead, it gives the error below, whether in Python directly or in the django environment. How do I fix this? I need to be able to import cx_Oracle in django! Thanks!
ImportError: dlopen(/Users/shawn/Virtual/Django18/lib/python2.7/site-packages/cx_Oracle.so,
2): Library not loaded: /Users/Shawn/Oracle/instantclient_11_2/
Referenced from: /Users/shawn/Virtual/Django18/lib/python2.7/site-packages/cx_Oracle.so
Reason: no suitable image found. Did find:
/Users/Shawn/Oracle/instantclient_11_2/: not a file
/Users/Shawn/Oracle/instantclient_11_2/: not a file
/usr/local/lib/: not a file
/usr/lib/: not a file
EDIT:
I wiped and recreated my virtualenv. I then retried the Ruby script after I realized that I didn't run it in the same directory as the instant client executables. It ran and updated from
#executable_path/...
to
/Users/shawn/Oracle/...
I tried importing cx_Oracle in my virtualenv python and this time it worked instead of throwing an error. Unfortunately, trying to run my django server still blows up saying
Raise ImproperlyConfigured("Error loading cx_Oracle module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading cx_Oracle module: dlopen(/Users/shawn/Virtual/Django18/lib/python2.7/site-packages/cx_Oracle.so, 2): Library not loaded: libclntsh.dylib.11.1
Referenced from: /Users/shawn/Virtual/Django18/lib/python2.7/site-packages/cx_Oracle.so
Reason: image not found
I can't understand why python can import it but django cannot.
Follow the instructions at the bottom of this page to do the installation of the Oracle instant client:
http://www.oracle.com/technetwork/topics/intel-macsoft-096467.html
You may also need to set DYLD_LIBRARY_PATH or adjust things using otool -L and install_name_tool.

Issue with using protobufs with python ImportError: cannot import name descriptor_pb2

Context
Steps taken:
Environment Setup
I've installed protobufs via Home Brew
I've also followed the steps in the proto-bufs python folder's readme on installing python protobufs - namely running the python setup.py install command
I've using the protobuf-2.4.1 files
Coding
I have a python file (generated from a .proto file I compiled) that contains the statement, among other import statements, but I believe this one is the one causing issues:
from google.protobuf import descriptor_pb2
The above python file, I'm importing in another python file, it's
this python file that I want to write up logic for parsing the
protobufs data files I receive
Error received
I get this error when running that file:
Steps taken to fix
Searched google for that error - didn't find much
Looked at this question/answer Why do I see "cannot import name descriptor_pb2" error when using Google Protocol Buffers?
I don't really understand the above questions selected answer,I tried to run the command in the above answer protoc descriptor.proto --python_out=gen/ by coping and pasting it in the terminal in different places but couldn't get it to work
Question
How do I fix this error?
What is the underlying cause?
How do I check if the rest of my protobuf python compiler/classes are set up correctly?
I've discovered the issue. I had not run the python install instructions the first time I tried to compile this file. I recompiled the file and this issue was fixed.

Mercurial installation issue

We've installed mercurial 1.4.1 and python 2.6.2 on a solaris 8 box. Now some hg commands work as expected, others fail.
I was able to initialize a repository (hg init) and add a file (hg add) but the committing (hg commit) leads to an error message:
abort: could not import module found!
I need a hint where to look - I'm not a python expert, is this missing found module part of the python distribution or does it belong to mercurial? Any idea how to fix it?
Edit
Thanks for your comments - hg debuginstall runs fine, just reports one problem - I didn't set a username in any of the config files. Can't believe that this causes the actual problems...
Edit
--traceback was a good hint!!
Here's the last line (can't copy&paste):
ImportError: ld.so.1: hg: fatal: relocation error:
file:/usr/local/lib/python2.6/lib-dynload/zlib.so:
symbol inflateCopy: referenced symbol not found
The zlib.so library is present was installed with either the python or mercurial package.
Looks like I'm not the only one: here's the same problem with python 2.5 on solaris 10
You need to install the zlib library for your system (libz.so).
Check your LD_LIBRARY_PATH settings.
If it is pulling libz from an odd place you will need to fix it so that it is pulling from /pkg/local/lib first
I was seeing this:
ldd /pkg/local/lib/python2.7/lib-dynload/zlib.so
libz.so => /import/wgs/lib/libz.so
But now its working for me.

How can I tell python which version of libmysqlclient.so to use?

I'm running a python script on a shared hosting server which until this morning had MySQL version 4. Now it has version 5. My python script can no longer connect to MySQL, as it can't find libmysqlclient_r.so.14:
$ python my_script.py
Traceback (most recent call last):
File "my_script.py", line 6, in ?
import MySQLdb
File "/home/lib/python2.4/site-packages/PIL-1.1.6-py2.4-linux-i686.egg/__init__.py", line 19, in ?
File "build/bdist.linux-i686/egg/_mysql.py", line 7, in ?
File "build/bdist.linux-i686/egg/_mysql.py", line 6, in __bootstrap__
ImportError: libmysqlclient_r.so.14: cannot open shared object file: No such file or directory
There are various other versions of libmysqlclient in /usr/lib:
/usr/lib/libmysqlclient.so.15
/usr/lib/libmysqlclient.so.14
/usr/lib/mysql/libmysqlclient.la
/usr/lib/mysql/libmysqlclient.so
/usr/lib/mysql/libmysqlclient_r.so
/usr/lib/mysql/libmysqlclient_r.a
/usr/lib/mysql/libmysqlclient_r.la
/usr/lib/mysql/libmysqlclient.a
/usr/lib/libmysqlclient.so
/usr/lib/libmysqlclient_r.so
/usr/lib/libmysqlclient_r.so.15
/usr/lib/libmysqlclient_r.so.15.0.0
/usr/lib/libmysqlclient.so.15.0.0
So my question is this: how can I tell python (version 2.4.3) which version of libmysqlclient to use?
You can't tell the dynamic linker which version of a library to use, because the SONAME (full name of the library + interface) is part of the binary.
In your case, you can try to upload libmysqlclient_r.so.14 to the host and set LD_LIBRARY_PATH accordingly, so tell the dynamic linker which directories to search additionally to the system dirs when resolving shared objects.
You can use ldd to see if it LD_LIBRARY_PATH works:
$ ldd $path_to/_mysql.so
...
libmysqlclient_r.so.14 => $path_to_lib/libmysqlclient_r.so.14
...
Otherwise, there will be an error message about unresolved shared objects.
Of course that can only be a temporary fix until you rebuild MySQLdb to use the new libraries.
You will have to recompile python-mysql (aka MySQLdb) to get it to link to the new version of libmysqlclient.
If your host originally set up the environment rather than you compiling it, you'll have to pester them.
/usr/lib/libmysqlclient.so.14
This looks like a remnant of the old libmysqlclient, and should be removed. The _r and .a (static) versions are gone and you don't really want a mixture of libraries still around, it will only risk confusing automake.
Whilst you could make a symbolic link from libmysqlclient_r.so.14 to .15, that'd only work if the new version of the client happened to have the same ABI for the functions you wanted to use as the old - and that's pretty unlikely, as that's the whole point of changing the version number.
One solution is to set your PYTHONPATH environment variable to have some local directory, and copy over (or link, I suppose) the version of the mysql lib you want.

Categories