This probably has been discussed many times, but I still can't find any solution yet. Basically, it turns out that python can load MySQLdb just fine, but Apache can't load MySQLdb from the wsgi script.
Here is the configuration of my machine. Mac OS X Snow Leopard 10.6.8 Apache2 (shipped with Snow Leopard) Python 2.7 (from python.org) virtualenv MySQL-python 1.2.3
BTW, I can import MySQLdb with no problem under python interpreter.
I am using python2.7 in a virtual environment created by virtualenv. Here is the error info extracted from the Apache error log. To make the lines shorter, I deleted all the time tags in the brackets.
Any ideas how to fix it?
[] mod_wsgi (pid=3136): Target WSGI script '/Users/jianbao/projects/ tao.com/mysite/apache/django.wsgi' cannot be loaded as Python module. [] mod_wsgi (pid=3136): Exception occurred processing WSGI script '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi'. [] Traceback (most recent call last): [] File "/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi", line 56, in <module> [] import MySQLdb [] File "/Users/jianbao/projects/ tao.com/mysite/lib/python2.7/site-packages/MySQLdb/__init__.py", line 19, in <module> [] import _mysql [] ImportError: dlopen(/Users/jianbao/projects/ tao.com/mysite/lib/python2.7/site-packages/_mysql.so, 2): Library not loaded: libmysqlclient.18.dylib [] Referenced from: /Users/jianbao/projects/ tao.com/mysite/lib/python2.7/site-packages/_mysql.so [] Reason: image not found
On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote:
> Hello folks, > This probably has been discussed many times, but I still can't find any > solution yet. Basically, it turns out that python can load MySQLdb just > fine, but Apache can't load MySQLdb from the wsgi script. > Here is the configuration of my machine. > Mac OS X Snow Leopard 10.6.8 > Apache2 (shipped with Snow Leopard)
Which is fat and by default will run as 64 bit.
> Python 2.7 (from python.org)
Which I believe now comes as fat binary so should be okay.
> virtualenv > MySQL-python 1.2.3
This is where problems start.
Because Apache is going to run as 64 bit, and because MySQL client libraries are not fat but for a specific architecture, you need to ensure you installed 64 bit MySQL and not 32 but version.
> BTW, I can import MySQLdb with no problem under python interpreter. > I am using python2.7 in a virtual environment created by virtualenv. Here is > the error info extracted from the Apache error log. To make the lines > shorter, I deleted all the time tags in the brackets. > Any ideas how to fix it? > [] mod_wsgi (pid=3136): Target WSGI script > '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi' cannot be loaded > as Python module. > [] mod_wsgi (pid=3136): Exception occurred processing WSGI script > '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi'. > [] Traceback (most recent call last): > [] File "/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi", line > 56, in <module> > [] import MySQLdb > [] File > "/Users/jianbao/projects/tao.com/mysite/lib/python2.7/site-packages/MySQLdb /__init__.py", > line 19, in <module> > [] import _mysql > [] ImportError: > dlopen(/Users/jianbao/projects/tao.com/mysite/lib/python2.7/site-packages/_ mysql.so, > 2): Library not loaded: libmysqlclient.18.dylib > [] Referenced from: > /Users/jianbao/projects/tao.com/mysite/lib/python2.7/site-packages/_mysql.s o > [] Reason: image not found
> -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/modwsgi/-/_S2GuYUGqosJ. > To post to this group, send email to modwsgi@googlegroups.com. > To unsubscribe from this group, send email to > modwsgi+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en.
Thank you so much, Graham. You may have pointed me to the right direction.
So, the following is what I get, where I basically filed all libmysqlclient* files under /usr/local/mysql/lib/. It seems the mysql I installed is for i386 architecture, but all the libmysqlclient files seem for x86_64, which is really confusing. Anyway, do you have any ideas of what's happening here?
>$ mysql --version
mysql Ver 14.14 Distrib 5.5.14, for osx10.6 (i386) using readline 5.1
graham.dumple...@gmail.com> wrote: > On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote: > > Hello folks, > > This probably has been discussed many times, but I still can't find any > > solution yet. Basically, it turns out that python can load MySQLdb just > > fine, but Apache can't load MySQLdb from the wsgi script. > > Here is the configuration of my machine. > > Mac OS X Snow Leopard 10.6.8 > > Apache2 (shipped with Snow Leopard)
> Which is fat and by default will run as 64 bit.
> > Python 2.7 (from python.org)
> Which I believe now comes as fat binary so should be okay.
> > virtualenv > > MySQL-python 1.2.3
> This is where problems start.
> Because Apache is going to run as 64 bit, and because MySQL client > libraries are not fat but for a specific architecture, you need to > ensure you installed 64 bit MySQL and not 32 but version.
> I suspect you will find that yours is only 32 bit and not 64 bit. That > is why you would get error:
> Reason: image not found
> Can you run the 'file' command on the dylib and see what it says.
> Graham
> > BTW, I can import MySQLdb with no problem under python interpreter. > > I am using python2.7 in a virtual environment created by virtualenv. Here > is > > the error info extracted from the Apache error log. To make the lines > > shorter, I deleted all the time tags in the brackets. > > Any ideas how to fix it? > > [] mod_wsgi (pid=3136): Target WSGI script > > '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi' cannot be > loaded > > as Python module. > > [] mod_wsgi (pid=3136): Exception occurred processing WSGI script > > '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi'. > > [] Traceback (most recent call last): > > [] File "/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi", > line > > 56, in <module> > > [] import MySQLdb > > [] File > > "/Users/jianbao/projects/ > tao.com/mysite/lib/python2.7/site-packages/MySQLdb/__init__.py", > > line 19, in <module> > > [] import _mysql > > [] ImportError: > > dlopen(/Users/jianbao/projects/ > tao.com/mysite/lib/python2.7/site-packages/_mysql.so, > > 2): Library not loaded: libmysqlclient.18.dylib > > [] Referenced from: > > /Users/jianbao/projects/ > tao.com/mysite/lib/python2.7/site-packages/_mysql.so > > [] Reason: image not found
> > -- > > You received this message because you are subscribed to the Google Groups > > "modwsgi" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/modwsgi/-/_S2GuYUGqosJ. > > To post to this group, send email to modwsgi@googlegroups.com. > > To unsubscribe from this group, send email to > > modwsgi+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/modwsgi?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to modwsgi@googlegroups.com. > To unsubscribe from this group, send email to > modwsgi+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en.
What do you get if you run 'file' on _mysql.so extension module file in Python installation? Also run 'otool -L _mysql.so' as well to see what library it is finding. You have 64 bit libraries so should be okay unless you have 32 bit somewhere else and it is finding that instead.
Graham
On Wednesday, 24 August 2011, Jianbao Tao <jianbao....@gmail.com> wrote: > Thank you so much, Graham. You may have pointed me to the right direction. > So, the following is what I get, where I basically filed all
libmysqlclient* files under /usr/local/mysql/lib/. It seems the mysql I installed is for i386 architecture, but all the libmysqlclient files seem for x86_64, which is really confusing. Anyway, do you have any ideas of what's happening here?
>>$ mysql --version > mysql Ver 14.14 Distrib 5.5.14, for osx10.6 (i386) using readline 5.1 >>$ ls /usr/local/mysql/lib/libmysqlclient* > /usr/local/mysql/lib/libmysqlclient.18.dylib
>>$ file /usr/local/mysql/lib/libmysqlclient_r.a > /usr/local/mysql/lib/libmysqlclient_r.a: current ar archive random library
> On Tue, Aug 23, 2011 at 5:09 PM, Graham Dumpleton < graham.dumple...@gmail.com> wrote:
> On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote: >> Hello folks, >> This probably has been discussed many times, but I still can't find any >> solution yet. Basically, it turns out that python can load MySQLdb just >> fine, but Apache can't load MySQLdb from the wsgi script. >> Here is the configuration of my machine. >> Mac OS X Snow Leopard 10.6.8 >> Apache2 (shipped with Snow Leopard)
> Which is fat and by default will run as 64 bit.
>> Python 2.7 (from python.org)
> Which I believe now comes as fat binary so should be okay.
>> virtualenv >> MySQL-python 1.2.3
> This is where problems start.
> Because Apache is going to run as 64 bit, and because MySQL client > libraries are not fat but for a specific architecture, you need to > ensure you installed 64 bit MySQL and not 32 but version.
> I suspect you will find that yours is only 32 bit and not 64 bit. That > is why you would get error:
> Reason: image not found
> Can you run the 'file' command on the dylib and see what it says.
> Graham
>> BTW, I can import MySQLdb with no problem under python interpreter. >> I am using python2.7 in a virtual environment created by virtualenv. Here is >> the error info extracted from the Apache error log. To make the lines >> shorter, I deleted all the time tags in the brackets. >> Any ideas how to fix it? >> [] mod_wsgi (pid=3136): Target WSGI script >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi' cannot be loaded >> as Python module. >> [] mod_wsgi (pid=3136): Exception occurred processing WSGI script >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi'. >> [] Traceback (most recent call last): >> [] File "/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi", line >> 56, in <module> >> [] import MySQLdb >> [] File >> "/Users/jianbao/projects/
>> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/modwsgi/-/_S2GuYUGqosJ. >> To post to this group, send email to modwsgi@googlegroups.com. >> To unsubscribe from this group, send email to >> modwsgi+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/modwsgi?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "modwsgi" group. > To post to this group, send email to
> -- > You received this message because you are subscribed to the Google Groups "modwsgi" group. > To post to this group, send email to modwsgi@googlegroups.com. > To unsubscribe from this group, send email to
./lib/python2.7/site-packages/_mysql.so: libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
So, it seems _mysql.so is already for x86_64 architecture. But there is a inconsistency about libSystem.B.dylib according the versions reported by otool. But I am not sure if that dylib is ever used by MySQLdb or not.
Any thoughts?
Jim
On Tue, Aug 23, 2011 at 6:41 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote: > What do you get if you run 'file' on _mysql.so extension module file in > Python installation? Also run 'otool -L _mysql.so' as well to see what > library it is finding. You have 64 bit libraries so should be okay unless > you have 32 bit somewhere else and it is finding that instead.
> Graham
> On Wednesday, 24 August 2011, Jianbao Tao <jianbao....@gmail.com> wrote: > > Thank you so much, Graham. You may have pointed me to the right > direction. > > So, the following is what I get, where I basically filed all > libmysqlclient* files under /usr/local/mysql/lib/. It seems the mysql I > installed is for i386 architecture, but all the libmysqlclient files seem > for x86_64, which is really confusing. Anyway, do you have any ideas of > what's happening here? > >>$ mysql --version > > mysql Ver 14.14 Distrib 5.5.14, for osx10.6 (i386) using readline 5.1 > >>$ ls /usr/local/mysql/lib/libmysqlclient* > > /usr/local/mysql/lib/libmysqlclient.18.dylib > /usr/local/mysql/lib/libmysqlclient_r.18.dylib > > /usr/local/mysql/lib/libmysqlclient.a > /usr/local/mysql/lib/libmysqlclient_r.a > > /usr/local/mysql/lib/libmysqlclient.dylib > /usr/local/mysql/lib/libmysqlclient_r.dylib > >>$ file /usr/local/mysql/lib/libmysqlclient.18.dylib > > /usr/local/mysql/lib/libmysqlclient.18.dylib: Mach-O 64-bit dynamically > linked shared library x86_64 > >>$ file /usr/local/mysql/lib/libmysqlclient.dylib > > /usr/local/mysql/lib/libmysqlclient.dylib: Mach-O 64-bit dynamically > linked shared library x86_64 > >>$ file /usr/local/mysql/lib/libmysqlclient.a > > /usr/local/mysql/lib/libmysqlclient.a: current ar archive random library > >>$ file /usr/local/mysql/lib/libmysqlclient_r.18.dylib > > /usr/local/mysql/lib/libmysqlclient_r.18.dylib: Mach-O 64-bit dynamically > linked shared library x86_64 > >>$ file /usr/local/mysql/lib/libmysqlclient_r.dylib > > /usr/local/mysql/lib/libmysqlclient_r.dylib: Mach-O 64-bit dynamically > linked shared library x86_64 > >>$ file /usr/local/mysql/lib/libmysqlclient_r.a > > /usr/local/mysql/lib/libmysqlclient_r.a: current ar archive random > library
> > On Tue, Aug 23, 2011 at 5:09 PM, Graham Dumpleton < > graham.dumple...@gmail.com> wrote:
> > On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote: > >> Hello folks, > >> This probably has been discussed many times, but I still can't find any > >> solution yet. Basically, it turns out that python can load MySQLdb just > >> fine, but Apache can't load MySQLdb from the wsgi script. > >> Here is the configuration of my machine. > >> Mac OS X Snow Leopard 10.6.8 > >> Apache2 (shipped with Snow Leopard)
> > Which is fat and by default will run as 64 bit.
> >> Python 2.7 (from python.org)
> > Which I believe now comes as fat binary so should be okay.
> >> virtualenv > >> MySQL-python 1.2.3
> > This is where problems start.
> > Because Apache is going to run as 64 bit, and because MySQL client > > libraries are not fat but for a specific architecture, you need to > > ensure you installed 64 bit MySQL and not 32 but version.
> > I suspect you will find that yours is only 32 bit and not 64 bit. That > > is why you would get error:
> > Reason: image not found
> > Can you run the 'file' command on the dylib and see what it says.
> > Graham
> >> BTW, I can import MySQLdb with no problem under python interpreter. > >> I am using python2.7 in a virtual environment created by virtualenv. > Here is > >> the error info extracted from the Apache error log. To make the lines > >> shorter, I deleted all the time tags in the brackets. > >> Any ideas how to fix it? > >> [] mod_wsgi (pid=3136): Target WSGI script > >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi' cannot be > loaded > >> as Python module. > >> [] mod_wsgi (pid=3136): Exception occurred processing WSGI script > >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi'. > >> [] Traceback (most recent call last): > >> [] File "/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi", > line > >> 56, in <module> > >> [] import MySQLdb > >> [] File > >> "/Users/jianbao/projects/ > tao.com/mysite/lib/python2.7/site-packages/MySQLdb/__init__.py", > >> line 19, in <module> > >> [] import _mysql > >> [] ImportError: > >> dlopen(/Users/jianbao/projects/ > tao.com/mysite/lib/python2.7/site-packages/_mysql.so, > >> 2): Library not loaded: libmysqlclient.18.dylib > >> [] Referenced from: > >> /Users/jianbao/projects/ > tao.com/mysite/lib/python2.7/site-packages/_mysql.so > >> [] Reason: image not found
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "modwsgi" group. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msg/modwsgi/-/_S2GuYUGqosJ. > >> To post to this group, send email to modwsgi@googlegroups.com. > >> To unsubscribe from this group, send email to > >> modwsgi+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/modwsgi?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > > To post to this group, send email to
> > -- > > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > > To post to this group, send email to modwsgi@googlegroups.com. > > To unsubscribe from this group, send email to > modwsgi+unsubscribe@googlegroups.com < > modwsgi%2Bunsubscribe@googlegroups.com>.
> -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to modwsgi@googlegroups.com. > To unsubscribe from this group, send email to > modwsgi+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en.
On 24 August 2011 12:31, Jianbao Tao <jianbao....@gmail.com> wrote:
> Graham, > This is what I got. >>$ file ./lib/python2.7/site-packages/_mysql.so > ./lib/python2.7/site-packages/_mysql.so: Mach-O 64-bit bundle x86_64 >>$ otool -L ./lib/python2.7/site-packages/_mysql.so > ./lib/python2.7/site-packages/_mysql.so: > libmysqlclient.18.dylib (compatibility version 18.0.0, current version > 18.0.0)
Can you change working directory and run this again with full path name to _mysql.so.
It says libmysqlclient.18.dylib but missing full path context to know for sure where that is coming from.
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 125.2.0) > So, it seems _mysql.so is already for x86_64 architecture. But there is a > inconsistency about libSystem.B.dylib according the versions reported by > otool. But I am not sure if that dylib is ever used by MySQLdb or not.
No so worried about the system library versioning. Probably normal.
> Any thoughts? > Jim > On Tue, Aug 23, 2011 at 6:41 PM, Graham Dumpleton > <graham.dumple...@gmail.com> wrote:
>> What do you get if you run 'file' on _mysql.so extension module file in >> Python installation? Also run 'otool -L _mysql.so' as well to see what >> library it is finding. You have 64 bit libraries so should be okay unless >> you have 32 bit somewhere else and it is finding that instead.
>> Graham
>> On Wednesday, 24 August 2011, Jianbao Tao <jianbao....@gmail.com> wrote: >> > Thank you so much, Graham. You may have pointed me to the right >> > direction. >> > So, the following is what I get, where I basically filed all >> > libmysqlclient* files under /usr/local/mysql/lib/. It seems the mysql I >> > installed is for i386 architecture, but all the libmysqlclient files seem >> > for x86_64, which is really confusing. Anyway, do you have any ideas of >> > what's happening here? >> >>$ mysql --version >> > mysql Ver 14.14 Distrib 5.5.14, for osx10.6 (i386) using readline 5.1 >> >>$ ls /usr/local/mysql/lib/libmysqlclient* >> > /usr/local/mysql/lib/libmysqlclient.18.dylib >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib >> > /usr/local/mysql/lib/libmysqlclient.a >> > /usr/local/mysql/lib/libmysqlclient_r.a >> > /usr/local/mysql/lib/libmysqlclient.dylib >> > /usr/local/mysql/lib/libmysqlclient_r.dylib >> >>$ file /usr/local/mysql/lib/libmysqlclient.18.dylib >> > /usr/local/mysql/lib/libmysqlclient.18.dylib: Mach-O 64-bit dynamically >> > linked shared library x86_64 >> >>$ file /usr/local/mysql/lib/libmysqlclient.dylib >> > /usr/local/mysql/lib/libmysqlclient.dylib: Mach-O 64-bit dynamically >> > linked shared library x86_64 >> >>$ file /usr/local/mysql/lib/libmysqlclient.a >> > /usr/local/mysql/lib/libmysqlclient.a: current ar archive random library >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.18.dylib >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib: Mach-O 64-bit >> > dynamically linked shared library x86_64 >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.dylib >> > /usr/local/mysql/lib/libmysqlclient_r.dylib: Mach-O 64-bit dynamically >> > linked shared library x86_64 >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.a >> > /usr/local/mysql/lib/libmysqlclient_r.a: current ar archive random >> > library
>> > On Tue, Aug 23, 2011 at 5:09 PM, Graham Dumpleton >> > <graham.dumple...@gmail.com> wrote:
>> > On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote: >> >> Hello folks, >> >> This probably has been discussed many times, but I still can't find any >> >> solution yet. Basically, it turns out that python can load MySQLdb just >> >> fine, but Apache can't load MySQLdb from the wsgi script. >> >> Here is the configuration of my machine. >> >> Mac OS X Snow Leopard 10.6.8 >> >> Apache2 (shipped with Snow Leopard)
>> > Which is fat and by default will run as 64 bit.
>> >> Python 2.7 (from python.org)
>> > Which I believe now comes as fat binary so should be okay.
>> >> virtualenv >> >> MySQL-python 1.2.3
>> > This is where problems start.
>> > Because Apache is going to run as 64 bit, and because MySQL client >> > libraries are not fat but for a specific architecture, you need to >> > ensure you installed 64 bit MySQL and not 32 but version.
>> > I suspect you will find that yours is only 32 bit and not 64 bit. That >> > is why you would get error:
>> > Reason: image not found
>> > Can you run the 'file' command on the dylib and see what it says.
>> > Graham
>> >> BTW, I can import MySQLdb with no problem under python interpreter. >> >> I am using python2.7 in a virtual environment created by virtualenv. >> >> Here is >> >> the error info extracted from the Apache error log. To make the lines >> >> shorter, I deleted all the time tags in the brackets. >> >> Any ideas how to fix it? >> >> [] mod_wsgi (pid=3136): Target WSGI script >> >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi' cannot be >> >> loaded >> >> as Python module. >> >> [] mod_wsgi (pid=3136): Exception occurred processing WSGI script >> >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi'. >> >> [] Traceback (most recent call last): >> >> [] File "/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi", >> >> line >> >> 56, in <module> >> >> [] import MySQLdb >> >> [] File
>> >> "/Users/jianbao/projects/tao.com/mysite/lib/python2.7/site-packages/MySQLdb /__init__.py", >> >> line 19, in <module> >> >> [] import _mysql >> >> [] ImportError:
>> >> /Users/jianbao/projects/tao.com/mysite/lib/python2.7/site-packages/_mysql.s o >> >> [] Reason: image not found
>> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "modwsgi" group. >> >> To view this discussion on the web visit >> >> https://groups.google.com/d/msg/modwsgi/-/_S2GuYUGqosJ. >> >> To post to this group, send email to modwsgi@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> modwsgi+unsubscribe@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/modwsgi?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "modwsgi" group. >> > To post to this group, send email to
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "modwsgi" group. >> > To post to this group, send email to modwsgi@googlegroups.com. >> > To unsubscribe from this group, send email to >> > modwsgi+unsubscribe@googlegroups.com <modwsgi%2Bunsubscribe@googlegroups.com>. >> > For more options, visit this group at >> > http://groups.google.com/group/modwsgi?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To post to this group, send email to modwsgi@googlegroups.com. >> To unsubscribe from this group, send email to >> modwsgi+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/modwsgi?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to modwsgi@googlegroups.com. > To unsubscribe from this group, send email to > modwsgi+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en.
tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so /Users/jianbao/projects/ tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so: libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
I don't see why full path would make any difference, though.
Any thoughts?
Jim
On Tue, Aug 23, 2011 at 9:39 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote: > On 24 August 2011 12:31, Jianbao Tao <jianbao....@gmail.com> wrote: > > Graham, > > This is what I got. > >>$ file ./lib/python2.7/site-packages/_mysql.so > > ./lib/python2.7/site-packages/_mysql.so: Mach-O 64-bit bundle x86_64 > >>$ otool -L ./lib/python2.7/site-packages/_mysql.so > > ./lib/python2.7/site-packages/_mysql.so: > > libmysqlclient.18.dylib (compatibility version 18.0.0, current version > > 18.0.0)
> Can you change working directory and run this again with full path > name to _mysql.so.
> It says libmysqlclient.18.dylib but missing full path context to know > for sure where that is coming from.
> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > > 125.2.0) > > So, it seems _mysql.so is already for x86_64 architecture. But there is a > > inconsistency about libSystem.B.dylib according the versions reported by > > otool. But I am not sure if that dylib is ever used by MySQLdb or not.
> No so worried about the system library versioning. Probably normal.
> Graham
> > Any thoughts? > > Jim > > On Tue, Aug 23, 2011 at 6:41 PM, Graham Dumpleton > > <graham.dumple...@gmail.com> wrote:
> >> What do you get if you run 'file' on _mysql.so extension module file in > >> Python installation? Also run 'otool -L _mysql.so' as well to see what > >> library it is finding. You have 64 bit libraries so should be okay > unless > >> you have 32 bit somewhere else and it is finding that instead.
> >> Graham
> >> On Wednesday, 24 August 2011, Jianbao Tao <jianbao....@gmail.com> > wrote: > >> > Thank you so much, Graham. You may have pointed me to the right > >> > direction. > >> > So, the following is what I get, where I basically filed all > >> > libmysqlclient* files under /usr/local/mysql/lib/. It seems the mysql > I > >> > installed is for i386 architecture, but all the libmysqlclient files > seem > >> > for x86_64, which is really confusing. Anyway, do you have any ideas > of > >> > what's happening here? > >> >>$ mysql --version > >> > mysql Ver 14.14 Distrib 5.5.14, for osx10.6 (i386) using readline 5.1 > >> >>$ ls /usr/local/mysql/lib/libmysqlclient* > >> > /usr/local/mysql/lib/libmysqlclient.18.dylib > >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib > >> > /usr/local/mysql/lib/libmysqlclient.a > >> > /usr/local/mysql/lib/libmysqlclient_r.a > >> > /usr/local/mysql/lib/libmysqlclient.dylib > >> > /usr/local/mysql/lib/libmysqlclient_r.dylib > >> >>$ file /usr/local/mysql/lib/libmysqlclient.18.dylib > >> > /usr/local/mysql/lib/libmysqlclient.18.dylib: Mach-O 64-bit > dynamically > >> > linked shared library x86_64 > >> >>$ file /usr/local/mysql/lib/libmysqlclient.dylib > >> > /usr/local/mysql/lib/libmysqlclient.dylib: Mach-O 64-bit dynamically > >> > linked shared library x86_64 > >> >>$ file /usr/local/mysql/lib/libmysqlclient.a > >> > /usr/local/mysql/lib/libmysqlclient.a: current ar archive random > library > >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.18.dylib > >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib: Mach-O 64-bit > >> > dynamically linked shared library x86_64 > >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.dylib > >> > /usr/local/mysql/lib/libmysqlclient_r.dylib: Mach-O 64-bit dynamically > >> > linked shared library x86_64 > >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.a > >> > /usr/local/mysql/lib/libmysqlclient_r.a: current ar archive random > >> > library
> >> > On Tue, Aug 23, 2011 at 5:09 PM, Graham Dumpleton > >> > <graham.dumple...@gmail.com> wrote:
> >> > On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote: > >> >> Hello folks, > >> >> This probably has been discussed many times, but I still can't find > any > >> >> solution yet. Basically, it turns out that python can load MySQLdb > just > >> >> fine, but Apache can't load MySQLdb from the wsgi script. > >> >> Here is the configuration of my machine. > >> >> Mac OS X Snow Leopard 10.6.8 > >> >> Apache2 (shipped with Snow Leopard)
> >> > Which is fat and by default will run as 64 bit.
> >> >> Python 2.7 (from python.org)
> >> > Which I believe now comes as fat binary so should be okay.
> >> >> virtualenv > >> >> MySQL-python 1.2.3
> >> > This is where problems start.
> >> > Because Apache is going to run as 64 bit, and because MySQL client > >> > libraries are not fat but for a specific architecture, you need to > >> > ensure you installed 64 bit MySQL and not 32 but version.
> >> > I suspect you will find that yours is only 32 bit and not 64 bit. That > >> > is why you would get error:
> >> > Reason: image not found
> >> > Can you run the 'file' command on the dylib and see what it says.
> >> > Graham
> >> >> BTW, I can import MySQLdb with no problem under python interpreter. > >> >> I am using python2.7 in a virtual environment created by virtualenv. > >> >> Here is > >> >> the error info extracted from the Apache error log. To make the lines > >> >> shorter, I deleted all the time tags in the brackets. > >> >> Any ideas how to fix it? > >> >> [] mod_wsgi (pid=3136): Target WSGI script > >> >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi' cannot > be > >> >> loaded > >> >> as Python module. > >> >> [] mod_wsgi (pid=3136): Exception occurred processing WSGI script > >> >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi'. > >> >> [] Traceback (most recent call last): > >> >> [] File "/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi > ", > >> >> line > >> >> 56, in <module> > >> >> [] import MySQLdb > >> >> [] File
> >> >> /Users/jianbao/projects/ > tao.com/mysite/lib/python2.7/site-packages/_mysql.so > >> >> [] Reason: image not found
> >> >> -- > >> >> You received this message because you are subscribed to the Google > >> >> Groups > >> >> "modwsgi" group. > >> >> To view this discussion on the web visit > >> >> https://groups.google.com/d/msg/modwsgi/-/_S2GuYUGqosJ. > >> >> To post to this group, send email to modwsgi@googlegroups.com. > >> >> To unsubscribe from this group, send email to > >> >> modwsgi+unsubscribe@googlegroups.com. > >> >> For more options, visit this group at > >> >> http://groups.google.com/group/modwsgi?hl=en.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "modwsgi" group. > >> > To post to this group, send email to
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "modwsgi" group. > >> > To post to this group, send email to modwsgi@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > modwsgi+unsubscribe@googlegroups.com < > modwsgi%2Bunsubscribe@googlegroups.com>. > >> > For more options, visit this group at > >> > http://groups.google.com/group/modwsgi?hl=en.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "modwsgi" group. > >> To post to this group, send email to modwsgi@googlegroups.com. > >> To unsubscribe from this group, send email to > >> modwsgi+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/modwsgi?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > > "modwsgi" group. > > To post to this group, send email to modwsgi@googlegroups.com. > > To unsubscribe from this group, send email to > > modwsgi+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/modwsgi?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to modwsgi@googlegroups.com. > To unsubscribe from this group, send email to > modwsgi+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en.
On 24 August 2011 13:55, Jianbao Tao <jianbao....@gmail.com> wrote:
> Sure. Here is what I got. >>$ file >> /Users/jianbao/projects/tao.com/djangoSite/lib/python2.7/site-packages/_mys ql.so > /Users/jianbao/projects/tao.com/djangoSite/lib/python2.7/site-packages/_mys ql.so: > Mach-O 64-bit bundle x86_64 >>$ otool -L >> /Users/jianbao/projects/tao.com/djangoSite/lib/python2.7/site-packages/_mys ql.so > /Users/jianbao/projects/tao.com/djangoSite/lib/python2.7/site-packages/_mys ql.so: > libmysqlclient.18.dylib (compatibility version 18.0.0, current version > 18.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 125.2.0) > I don't see why full path would make any difference, though. > Any thoughts?
The otool output should show a full path name for 'libmysqlclient.18.dylib' else it is indicating that it didn't know where to find it. This worries me a bit as if otool doesn't know where it is coming from then under Apache it will not either. Ie., could not resolve it and thus why image not found.
This may be the actual problem. Ie., Apache doesn't know where to find the library at run time and not the 32 bit vs 64 bit issue.
> On Tue, Aug 23, 2011 at 9:39 PM, Graham Dumpleton > <graham.dumple...@gmail.com> wrote:
>> On 24 August 2011 12:31, Jianbao Tao <jianbao....@gmail.com> wrote: >> > Graham, >> > This is what I got. >> >>$ file ./lib/python2.7/site-packages/_mysql.so >> > ./lib/python2.7/site-packages/_mysql.so: Mach-O 64-bit bundle x86_64 >> >>$ otool -L ./lib/python2.7/site-packages/_mysql.so >> > ./lib/python2.7/site-packages/_mysql.so: >> > libmysqlclient.18.dylib (compatibility version 18.0.0, current version >> > 18.0.0)
>> Can you change working directory and run this again with full path >> name to _mysql.so.
>> It says libmysqlclient.18.dylib but missing full path context to know >> for sure where that is coming from.
>> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version >> > 125.2.0) >> > So, it seems _mysql.so is already for x86_64 architecture. But there is >> > a >> > inconsistency about libSystem.B.dylib according the versions reported by >> > otool. But I am not sure if that dylib is ever used by MySQLdb or not.
>> No so worried about the system library versioning. Probably normal.
>> Graham
>> > Any thoughts? >> > Jim >> > On Tue, Aug 23, 2011 at 6:41 PM, Graham Dumpleton >> > <graham.dumple...@gmail.com> wrote:
>> >> What do you get if you run 'file' on _mysql.so extension module file in >> >> Python installation? Also run 'otool -L _mysql.so' as well to see what >> >> library it is finding. You have 64 bit libraries so should be okay >> >> unless >> >> you have 32 bit somewhere else and it is finding that instead.
>> >> Graham
>> >> On Wednesday, 24 August 2011, Jianbao Tao <jianbao....@gmail.com> >> >> wrote: >> >> > Thank you so much, Graham. You may have pointed me to the right >> >> > direction. >> >> > So, the following is what I get, where I basically filed all >> >> > libmysqlclient* files under /usr/local/mysql/lib/. It seems the mysql >> >> > I >> >> > installed is for i386 architecture, but all the libmysqlclient files >> >> > seem >> >> > for x86_64, which is really confusing. Anyway, do you have any ideas >> >> > of >> >> > what's happening here? >> >> >>$ mysql --version >> >> > mysql Ver 14.14 Distrib 5.5.14, for osx10.6 (i386) using readline >> >> > 5.1 >> >> >>$ ls /usr/local/mysql/lib/libmysqlclient* >> >> > /usr/local/mysql/lib/libmysqlclient.18.dylib >> >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib >> >> > /usr/local/mysql/lib/libmysqlclient.a >> >> > /usr/local/mysql/lib/libmysqlclient_r.a >> >> > /usr/local/mysql/lib/libmysqlclient.dylib >> >> > /usr/local/mysql/lib/libmysqlclient_r.dylib >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.18.dylib >> >> > /usr/local/mysql/lib/libmysqlclient.18.dylib: Mach-O 64-bit >> >> > dynamically >> >> > linked shared library x86_64 >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.dylib >> >> > /usr/local/mysql/lib/libmysqlclient.dylib: Mach-O 64-bit dynamically >> >> > linked shared library x86_64 >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.a >> >> > /usr/local/mysql/lib/libmysqlclient.a: current ar archive random >> >> > library >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.18.dylib >> >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib: Mach-O 64-bit >> >> > dynamically linked shared library x86_64 >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.dylib >> >> > /usr/local/mysql/lib/libmysqlclient_r.dylib: Mach-O 64-bit >> >> > dynamically >> >> > linked shared library x86_64 >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.a >> >> > /usr/local/mysql/lib/libmysqlclient_r.a: current ar archive random >> >> > library
>> >> > On Tue, Aug 23, 2011 at 5:09 PM, Graham Dumpleton >> >> > <graham.dumple...@gmail.com> wrote:
>> >> > On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote: >> >> >> Hello folks, >> >> >> This probably has been discussed many times, but I still can't find >> >> >> any >> >> >> solution yet. Basically, it turns out that python can load MySQLdb >> >> >> just >> >> >> fine, but Apache can't load MySQLdb from the wsgi script. >> >> >> Here is the configuration of my machine. >> >> >> Mac OS X Snow Leopard 10.6.8 >> >> >> Apache2 (shipped with Snow Leopard)
>> >> > Which is fat and by default will run as 64 bit.
>> >> >> Python 2.7 (from python.org)
>> >> > Which I believe now comes as fat binary so should be okay.
>> >> >> virtualenv >> >> >> MySQL-python 1.2.3
>> >> > This is where problems start.
>> >> > Because Apache is going to run as 64 bit, and because MySQL client >> >> > libraries are not fat but for a specific architecture, you need to >> >> > ensure you installed 64 bit MySQL and not 32 but version.
>> >> > I suspect you will find that yours is only 32 bit and not 64 bit. >> >> > That >> >> > is why you would get error:
>> >> > Reason: image not found
>> >> > Can you run the 'file' command on the dylib and see what it says.
>> >> > Graham
>> >> >> BTW, I can import MySQLdb with no problem under python interpreter. >> >> >> I am using python2.7 in a virtual environment created by virtualenv. >> >> >> Here is >> >> >> the error info extracted from the Apache error log. To make the >> >> >> lines >> >> >> shorter, I deleted all the time tags in the brackets. >> >> >> Any ideas how to fix it? >> >> >> [] mod_wsgi (pid=3136): Target WSGI script >> >> >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi' cannot >> >> >> be >> >> >> loaded >> >> >> as Python module. >> >> >> [] mod_wsgi (pid=3136): Exception occurred processing WSGI script >> >> >> '/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi'. >> >> >> [] Traceback (most recent call last): >> >> >> [] File >> >> >> "/Users/jianbao/projects/tao.com/mysite/apache/django.wsgi", >> >> >> line >> >> >> 56, in <module> >> >> >> [] import MySQLdb >> >> >> [] File
>> >> >> /Users/jianbao/projects/tao.com/mysite/lib/python2.7/site-packages/_mysql.s o >> >> >> [] Reason: image not found
>> >> >> -- >> >> >> You received this message because you are subscribed to the Google >> >> >> Groups >> >> >> "modwsgi" group. >> >> >> To view this discussion on the web visit >> >> >> https://groups.google.com/d/msg/modwsgi/-/_S2GuYUGqosJ. >> >> >> To post to this group, send email to modwsgi@googlegroups.com. >> >> >> To unsubscribe from this group, send email to >> >> >> modwsgi+unsubscribe@googlegroups.com. >> >> >> For more options, visit this group at >> >> >> http://groups.google.com/group/modwsgi?hl=en.
>> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups "modwsgi" group. >> >> > To post to this group, send email to
>> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups "modwsgi" group. >> >> > To post to this group, send email to modwsgi@googlegroups.com. >> >> > To unsubscribe from this group, send email to
>> >> > modwsgi+unsubscribe@googlegroups.com <modwsgi%2Bunsubscribe@googlegroups.com>. >> >> > For more options, visit this group at >> >> > http://groups.google.com/group/modwsgi?hl=en.
>> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "modwsgi" group. >> >> To post to this group, send email to modwsgi@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> modwsgi+unsubscribe@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/modwsgi?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "modwsgi" group. >> > To post to this group, send email to modwsgi@googlegroups.com. >> > To unsubscribe from this group, send email to >> > modwsgi+unsubscribe@googlegroups.com. >> > For more
tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so /Users/jianbao/projects/ tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so: libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
Not so much of difference, though. Any ideas?
On Tue, Aug 23, 2011 at 10:10 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote: > On 24 August 2011 13:55, Jianbao Tao <jianbao....@gmail.com> wrote: > > Sure. Here is what I got. > >>$ file > >> /Users/jianbao/projects/ > tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so > > /Users/jianbao/projects/ > tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so: > > Mach-O 64-bit bundle x86_64 > >>$ otool -L > >> /Users/jianbao/projects/ > tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so > > /Users/jianbao/projects/ > tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so: > > libmysqlclient.18.dylib (compatibility version 18.0.0, current version > > 18.0.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > > 125.2.0) > > I don't see why full path would make any difference, though. > > Any thoughts?
> The otool output should show a full path name for > 'libmysqlclient.18.dylib' else it is indicating that it didn't know > where to find it. This worries me a bit as if otool doesn't know where > it is coming from then under Apache it will not either. Ie., could not > resolve it and thus why image not found.
> This may be the actual problem. Ie., Apache doesn't know where to find > the library at run time and not the 32 bit vs 64 bit issue.
> > On Tue, Aug 23, 2011 at 9:39 PM, Graham Dumpleton > > <graham.dumple...@gmail.com> wrote:
> >> On 24 August 2011 12:31, Jianbao Tao <jianbao....@gmail.com> wrote: > >> > Graham, > >> > This is what I got. > >> >>$ file ./lib/python2.7/site-packages/_mysql.so > >> > ./lib/python2.7/site-packages/_mysql.so: Mach-O 64-bit bundle x86_64 > >> >>$ otool -L ./lib/python2.7/site-packages/_mysql.so > >> > ./lib/python2.7/site-packages/_mysql.so: > >> > libmysqlclient.18.dylib (compatibility version 18.0.0, current version > >> > 18.0.0)
> >> Can you change working directory and run this again with full path > >> name to _mysql.so.
> >> It says libmysqlclient.18.dylib but missing full path context to know > >> for sure where that is coming from.
> >> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version > >> > 125.2.0) > >> > So, it seems _mysql.so is already for x86_64 architecture. But there > is > >> > a > >> > inconsistency about libSystem.B.dylib according the versions reported > by > >> > otool. But I am not sure if that dylib is ever used by MySQLdb or not.
> >> No so worried about the system library versioning. Probably normal.
> >> Graham
> >> > Any thoughts? > >> > Jim > >> > On Tue, Aug 23, 2011 at 6:41 PM, Graham Dumpleton > >> > <graham.dumple...@gmail.com> wrote:
> >> >> What do you get if you run 'file' on _mysql.so extension module file > in > >> >> Python installation? Also run 'otool -L _mysql.so' as well to see > what > >> >> library it is finding. You have 64 bit libraries so should be okay > >> >> unless > >> >> you have 32 bit somewhere else and it is finding that instead.
> >> >> Graham
> >> >> On Wednesday, 24 August 2011, Jianbao Tao <jianbao....@gmail.com> > >> >> wrote: > >> >> > Thank you so much, Graham. You may have pointed me to the right > >> >> > direction. > >> >> > So, the following is what I get, where I basically filed all > >> >> > libmysqlclient* files under /usr/local/mysql/lib/. It seems the > mysql > >> >> > I > >> >> > installed is for i386 architecture, but all the libmysqlclient > files > >> >> > seem > >> >> > for x86_64, which is really confusing. Anyway, do you have any > ideas > >> >> > of > >> >> > what's happening here? > >> >> >>$ mysql --version > >> >> > mysql Ver 14.14 Distrib 5.5.14, for osx10.6 (i386) using readline > >> >> > 5.1 > >> >> >>$ ls /usr/local/mysql/lib/libmysqlclient* > >> >> > /usr/local/mysql/lib/libmysqlclient.18.dylib > >> >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib > >> >> > /usr/local/mysql/lib/libmysqlclient.a > >> >> > /usr/local/mysql/lib/libmysqlclient_r.a > >> >> > /usr/local/mysql/lib/libmysqlclient.dylib > >> >> > /usr/local/mysql/lib/libmysqlclient_r.dylib > >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.18.dylib > >> >> > /usr/local/mysql/lib/libmysqlclient.18.dylib: Mach-O 64-bit > >> >> > dynamically > >> >> > linked shared library x86_64 > >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.dylib > >> >> > /usr/local/mysql/lib/libmysqlclient.dylib: Mach-O 64-bit > dynamically > >> >> > linked shared library x86_64 > >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.a > >> >> > /usr/local/mysql/lib/libmysqlclient.a: current ar archive random > >> >> > library > >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.18.dylib > >> >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib: Mach-O 64-bit > >> >> > dynamically linked shared library x86_64 > >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.dylib > >> >> > /usr/local/mysql/lib/libmysqlclient_r.dylib: Mach-O 64-bit > >> >> > dynamically > >> >> > linked shared library x86_64 > >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.a > >> >> > /usr/local/mysql/lib/libmysqlclient_r.a: current ar archive random > >> >> > library
> >> >> > On Tue, Aug 23, 2011 at 5:09 PM, Graham Dumpleton > >> >> > <graham.dumple...@gmail.com> wrote:
> >> >> > On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote: > >> >> >> Hello folks, > >> >> >> This probably has been discussed many times, but I still can't > find > >> >> >> any > >> >> >> solution yet. Basically, it turns out that python can load MySQLdb > >> >> >> just > >> >> >> fine, but Apache can't load MySQLdb from the wsgi script. > >> >> >> Here is the configuration of my machine. > >> >> >> Mac OS X Snow Leopard 10.6.8 > >> >> >> Apache2 (shipped with Snow Leopard)
> >> >> > Which is fat and by default will run as 64 bit.
> >> >> >> Python 2.7 (from python.org)
> >> >> > Which I believe now comes as fat binary so should be okay.
> >> >> > Because Apache is going to run as 64 bit, and because MySQL client > >> >> > libraries are not fat but for a specific architecture, you need to > >> >> > ensure you installed 64 bit MySQL and not 32 but version.
> >> >> >> /Users/jianbao/projects/ > tao.com/mysite/lib/python2.7/site-packages/_mysql.so > >> >> >> [] Reason: image not found
> >> >> >> -- > >> >> >> You received this message because you are subscribed to the Google > >> >> >> Groups > >> >> >> "modwsgi" group. > >> >> >> To view this discussion on the web visit > >> >> >> https://groups.google.com/d/msg/modwsgi/-/_S2GuYUGqosJ. > >> >> >> To post to this group, send email to modwsgi@googlegroups.com. > >> >> >> To unsubscribe from this group, send email to > >> >> >> modwsgi+unsubscribe@googlegroups.com. > >> >> >> For more options, visit this group at > >> >> >> http://groups.google.com/group/modwsgi?hl=en.
> >> >> > -- > >> >> > You received this message because you are subscribed to the Google > >> >> > Groups "modwsgi" group. > >> >> > To post to this group, send email to
> >> >> > -- > >> >> > You received this message because you are subscribed to the Google > >> >> > Groups
$ otool -L _mysql.so _mysql.so: /usr/local/mysql/lib/libmysqlclient_r.16.dylib (compatibility version 17.0.0, current version 17.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)
See what I mean about having full path. That way I know for sure that is being able to be found.
Without the full path, says that doesn't actually know where to find it.
What do you get for load commands related to libraries in the output.
Load command 7 cmd LC_LOAD_DYLIB cmdsize 72 name /usr/local/mysql/lib/libmysqlclient_r.16.dylib (offset 24) time stamp 2 Thu Jan 1 10:00:02 1970 current version 17.0.0 compatibility version 17.0.0 Load command 8 cmd LC_LOAD_DYLIB cmdsize 48 name /usr/lib/libz.1.dylib (offset 24) time stamp 2 Thu Jan 1 10:00:02 1970 current version 1.2.3 compatibility version 1.0.0 Load command 9 cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libSystem.B.dylib (offset 24) time stamp 2 Thu Jan 1 10:00:02 1970 current version 125.2.10 compatibility version 1.0.0
Graham
On 24 August 2011 14:19, Jianbao Tao <jianbao....@gmail.com> wrote:
> Alright. Here is what I got. >>$ DYLD_LIBRARY_PATH=/usr/local/mysql/lib otool -L >> /Users/jianbao/projects/tao.com/djangoSite/lib/python2.7/site-packages/_mys ql.so > /Users/jianbao/projects/tao.com/djangoSite/lib/python2.7/site-packages/_mys ql.so: > libmysqlclient.18.dylib (compatibility version 18.0.0, current version > 18.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 125.2.0) > Not so much of difference, though. Any ideas? > On Tue, Aug 23, 2011 at 10:10 PM, Graham Dumpleton > <graham.dumple...@gmail.com> wrote:
>> On 24 August 2011 13:55, Jianbao Tao <jianbao....@gmail.com> wrote: >> > Sure. Here is what I got. >> >>$ file
>> > /Users/jianbao/projects/tao.com/djangoSite/lib/python2.7/site-packages/_mys ql.so: >> > libmysqlclient.18.dylib (compatibility version 18.0.0, current version >> > 18.0.0) >> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version >> > 125.2.0) >> > I don't see why full path would make any difference, though. >> > Any thoughts?
>> The otool output should show a full path name for >> 'libmysqlclient.18.dylib' else it is indicating that it didn't know >> where to find it. This worries me a bit as if otool doesn't know where >> it is coming from then under Apache it will not either. Ie., could not >> resolve it and thus why image not found.
>> This may be the actual problem. Ie., Apache doesn't know where to find >> the library at run time and not the 32 bit vs 64 bit issue.
>> > On Tue, Aug 23, 2011 at 9:39 PM, Graham Dumpleton >> > <graham.dumple...@gmail.com> wrote:
>> >> On 24 August 2011 12:31, Jianbao Tao <jianbao....@gmail.com> wrote: >> >> > Graham, >> >> > This is what I got. >> >> >>$ file ./lib/python2.7/site-packages/_mysql.so >> >> > ./lib/python2.7/site-packages/_mysql.so: Mach-O 64-bit bundle x86_64 >> >> >>$ otool -L ./lib/python2.7/site-packages/_mysql.so >> >> > ./lib/python2.7/site-packages/_mysql.so: >> >> > libmysqlclient.18.dylib (compatibility version 18.0.0, current >> >> > version >> >> > 18.0.0)
>> >> Can you change working directory and run this again with full path >> >> name to _mysql.so.
>> >> It says libmysqlclient.18.dylib but missing full path context to know >> >> for sure where that is coming from.
>> >> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> >> > version >> >> > 125.2.0) >> >> > So, it seems _mysql.so is already for x86_64 architecture. But there >> >> > is >> >> > a >> >> > inconsistency about libSystem.B.dylib according the versions reported >> >> > by >> >> > otool. But I am not sure if that dylib is ever used by MySQLdb or >> >> > not.
>> >> No so worried about the system library versioning. Probably normal.
>> >> Graham
>> >> > Any thoughts? >> >> > Jim >> >> > On Tue, Aug 23, 2011 at 6:41 PM, Graham Dumpleton >> >> > <graham.dumple...@gmail.com> wrote:
>> >> >> What do you get if you run 'file' on _mysql.so extension module file >> >> >> in >> >> >> Python installation? Also run 'otool -L _mysql.so' as well to see >> >> >> what >> >> >> library it is finding. You have 64 bit libraries so should be okay >> >> >> unless >> >> >> you have 32 bit somewhere else and it is finding that instead.
>> >> >> Graham
>> >> >> On Wednesday, 24 August 2011, Jianbao Tao <jianbao....@gmail.com> >> >> >> wrote: >> >> >> > Thank you so much, Graham. You may have pointed me to the right >> >> >> > direction. >> >> >> > So, the following is what I get, where I basically filed all >> >> >> > libmysqlclient* files under /usr/local/mysql/lib/. It seems the >> >> >> > mysql >> >> >> > I >> >> >> > installed is for i386 architecture, but all the libmysqlclient >> >> >> > files >> >> >> > seem >> >> >> > for x86_64, which is really confusing. Anyway, do you have any >> >> >> > ideas >> >> >> > of >> >> >> > what's happening here? >> >> >> >>$ mysql --version >> >> >> > mysql Ver 14.14 Distrib 5.5.14, for osx10.6 (i386) using readline >> >> >> > 5.1 >> >> >> >>$ ls /usr/local/mysql/lib/libmysqlclient* >> >> >> > /usr/local/mysql/lib/libmysqlclient.18.dylib >> >> >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib >> >> >> > /usr/local/mysql/lib/libmysqlclient.a >> >> >> > /usr/local/mysql/lib/libmysqlclient_r.a >> >> >> > /usr/local/mysql/lib/libmysqlclient.dylib >> >> >> > /usr/local/mysql/lib/libmysqlclient_r.dylib >> >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.18.dylib >> >> >> > /usr/local/mysql/lib/libmysqlclient.18.dylib: Mach-O 64-bit >> >> >> > dynamically >> >> >> > linked shared library x86_64 >> >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.dylib >> >> >> > /usr/local/mysql/lib/libmysqlclient.dylib: Mach-O 64-bit >> >> >> > dynamically >> >> >> > linked shared library x86_64 >> >> >> >>$ file /usr/local/mysql/lib/libmysqlclient.a >> >> >> > /usr/local/mysql/lib/libmysqlclient.a: current ar archive random >> >> >> > library >> >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.18.dylib >> >> >> > /usr/local/mysql/lib/libmysqlclient_r.18.dylib: Mach-O 64-bit >> >> >> > dynamically linked shared library x86_64 >> >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.dylib >> >> >> > /usr/local/mysql/lib/libmysqlclient_r.dylib: Mach-O 64-bit >> >> >> > dynamically >> >> >> > linked shared library x86_64 >> >> >> >>$ file /usr/local/mysql/lib/libmysqlclient_r.a >> >> >> > /usr/local/mysql/lib/libmysqlclient_r.a: current ar archive random >> >> >> > library
>> >> >> > On Tue, Aug 23, 2011 at 5:09 PM, Graham Dumpleton >> >> >> > <graham.dumple...@gmail.com> wrote:
>> >> >> > On 24 August 2011 08:58, Jim <jianbao....@gmail.com> wrote: >> >> >> >> Hello folks, >> >> >> >> This probably has been discussed many times, but I still can't >> >> >> >> find >> >> >> >> any >> >> >> >> solution yet. Basically, it turns out that python can load >> >> >> >> MySQLdb >> >> >> >> just >> >> >> >> fine, but Apache can't load MySQLdb from the wsgi script. >> >> >> >> Here is the configuration of my machine. >> >> >> >> Mac OS X Snow Leopard 10.6.8 >> >> >> >> Apache2 (shipped with Snow Leopard)
>> >> >> > Which is fat and by default will run as 64 bit.
>> >> >> >> Python 2.7 (from python.org)
>> >> >> > Which I believe now comes as fat binary so should be okay.
>> >> >> > Because Apache is going to run as 64 bit, and because MySQL client >> >> >> > libraries are not fat but for a specific architecture, you need to >> >> >> > ensure you installed 64 bit MySQL and not 32 but version.
>> >> >> > I suspect you will find that yours is only 32 bit and not 64 bit. >> >> >> > That >> >> >> > is why you would get error:
>> >> >> > Reason: image not found
>> >> >> > Can you run the 'file' command on the dylib and see what it says.
>> >> >> > Graham
>> >> >> >> BTW, I can import MySQLdb with no problem under python >> >> >> >> interpreter. >> >> >> >> I am using python2.7 in a virtual environment created by >> >> >> >> virtualenv. >> >> >> >> Here is >> >> >> >> the error info
graham.dumple...@gmail.com> wrote: > When I do it I get:
> $ otool -L _mysql.so > _mysql.so: > /usr/local/mysql/lib/libmysqlclient_r.16.dylib (compatibility > version > 17.0.0, current version 17.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version > 1.2.3) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 125.2.10)
> See what I mean about having full path. That way I know for sure that > is being able to be found.
> Without the full path, says that doesn't actually know where to find it.
> What do you get for load commands related to libraries in the output.
> Load command 7 > cmd LC_LOAD_DYLIB > cmdsize 72 > name /usr/local/mysql/lib/libmysqlclient_r.16.dylib (offset 24) > time stamp 2 Thu Jan 1 10:00:02 1970 > current version 17.0.0 > compatibility version 17.0.0 > Load command 8 > cmd LC_LOAD_DYLIB > cmdsize 48 > name /usr/lib/libz.1.dylib (offset 24) > time stamp 2 Thu Jan 1 10:00:02 1970 > current version 1.2.3 > compatibility version 1.0.0 > Load command 9 > cmd LC_LOAD_DYLIB > cmdsize 56 > name /usr/lib/libSystem.B.dylib (offset 24) > time stamp 2 Thu Jan 1 10:00:02 1970 > current version 125.2.10 > compatibility version 1.0.0
> Graham
> On 24 August 2011 14:19, Jianbao Tao <jianbao....@gmail.com> wrote: > > Alright. Here is what I got. > >>$ DYLD_LIBRARY_PATH=/usr/local/mysql/lib otool -L > >> /Users/jianbao/projects/ > tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so > > /Users/jianbao/projects/ > tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so: > > libmysqlclient.18.dylib (compatibility version 18.0.0, current version > > 18.0.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > > 125.2.0) > > Not so much of difference, though. Any ideas? > > On Tue, Aug 23, 2011 at 10:10 PM, Graham Dumpleton > > <graham.dumple...@gmail.com> wrote:
> >> On 24 August 2011 13:55, Jianbao Tao <jianbao....@gmail.com> wrote: > >> > Sure. Here is what I got. > >> >>$ file
> >> > /Users/jianbao/projects/ > tao.com/djangoSite/lib/python2.7/site-packages/_mysql.so: > >> > libmysqlclient.18.dylib (compatibility version 18.0.0, current version > >> > 18.0.0) > >> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version > >> > 125.2.0) > >> > I don't see why full path would make any difference, though. > >> > Any thoughts?
> >> The otool output should show a full path name for > >> 'libmysqlclient.18.dylib' else it is indicating that it didn't know > >> where to find it. This worries me a bit as if otool doesn't know where > >> it is coming from then under Apache it will not either. Ie., could not > >> resolve it and thus why image not found.
> >> This may be the actual problem. Ie., Apache doesn't know where to find > >> the library at run time and not the 32 bit vs 64 bit issue.
Do you remember what you did when you build the MySQL-python package in the first place?
Did you explicitly put MySQL bin directory in PATH or did you modify the site.cfg file to say where it was?
Did you modify any of the default settings in site.cfg?
If you rebuilt it multiple times or have upgraded MySQL, did you start over building Python package from a clean source package and not one with existing build/dist directories present?
If you still have the source package and haven't cleaned it, what do you get for:
$ otool -L build/lib.macosx-10.6-universal-2.6/_mysql.so build/lib.macosx-10.6-universal-2.6/_mysql.so: /usr/local/mysql/lib/libmysqlclient_r.16.dylib (compatibility version 17.0.0, current version 17.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)
in the source package.
Right now thinking something went wrong with the original build.
Not only aren't you using the reentrant MySQL library, but no full path encoded for it.
Perhaps go back to fresh MySQL-python package and build again and show us the steps you did and the output as shown below as an example. Most interested to see the final link line, which for me is:
graham.dumple...@gmail.com> wrote: > Do you remember what you did when you build the MySQL-python package > in the first place?
> Did you explicitly put MySQL bin directory in PATH or did you modify > the site.cfg file to say where it was?
> Did you modify any of the default settings in site.cfg?
> If you rebuilt it multiple times or have upgraded MySQL, did you start > over building Python package from a clean source package and not one > with existing build/dist directories present?
> If you still have the source package and haven't cleaned it, what do > you get for:
> $ otool -L build/lib.macosx-10.6-universal-2.6/_mysql.so > build/lib.macosx-10.6-universal-2.6/_mysql.so: > /usr/local/mysql/lib/libmysqlclient_r.16.dylib (compatibility > version > 17.0.0, current version 17.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version > 1.2.3) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 125.2.10)
> in the source package.
> Right now thinking something went wrong with the original build.
> Not only aren't you using the reentrant MySQL library, but no full > path encoded for it.
> Perhaps go back to fresh MySQL-python package and build again and show > us the steps you did and the output as shown below as an example. Most > interested to see the final link line, which for me is:
On 25 August 2011 13:19, Jianbao Tao <jianbao....@gmail.com> wrote:
> Thank you, Graham. > I installed MySQL-python inside the virtual environment created by > virtualenv with > <shell> >>$ pip install MySQL-python
That could well be the problem. If mysql_config is not found when pip is running to do install it will not be able to link library properly. Looking in the code it does:
elif enabled(options, 'threadsafe'): libs = mysql_config("libs_r") client = "mysqlclient_r" if not libs: libs = mysql_config("libs") client = "mysqlclient"
So, mysql_config must have failed and so couldn't be sure that could use mysqlclient_r and used mysqlclient instead.
Further, because it didn't know where libs were, couldn't embed the proper library path to find library. Then at run time it isn't finding it or isn't liking it.
> </shell> > So, I don't really know what configuration pip used. I think I also built > MySQL-python from the source code before, but that didn't work out either.
Would still recommend you go back and try that and set PATH to include bin directory were mysql_config is located like I showed I did. Check with otool of _mysql.so in the build directory before installing it in virtual environment.
> On Wed, Aug 24, 2011 at 8:35 PM, Graham Dumpleton > <graham.dumple...@gmail.com> wrote:
>> Do you remember what you did when you build the MySQL-python package >> in the first place?
>> Did you explicitly put MySQL bin directory in PATH or did you modify >> the site.cfg file to say where it was?
>> Did you modify any of the default settings in site.cfg?
>> If you rebuilt it multiple times or have upgraded MySQL, did you start >> over building Python package from a clean source package and not one >> with existing build/dist directories present?
>> If you still have the source package and haven't cleaned it, what do >> you get for:
>> $ otool -L build/lib.macosx-10.6-universal-2.6/_mysql.so >> build/lib.macosx-10.6-universal-2.6/_mysql.so: >> /usr/local/mysql/lib/libmysqlclient_r.16.dylib (compatibility >> version >> 17.0.0, current version 17.0.0) >> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version >> 1.2.3) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 125.2.10)
>> in the source package.
>> Right now thinking something went wrong with the original build.
>> Not only aren't you using the reentrant MySQL library, but no full >> path encoded for it.
>> Perhaps go back to fresh MySQL-python package and build again and show >> us the steps you did and the output as shown below as an example. Most >> interested to see the final link line, which for me is:
>> -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2. 6 >> -c _mysql.c -o build/temp.macosx-10.6-universal-2.6/_mysql.o -g -Os >> -arch x86_64 -fno-common -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE >> -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT >> -DDONT_DECLARE_CXA_PURE_VIRTUAL >> In file included from _mysql.c:36: >> /usr/local/mysql/include/my_config.h:1069:1: warning: "HAVE_WCSCOLL" >> redefined >> In file included from
>> /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/ Python.h:8, >> from pymemcompat.h:10, >> from _mysql.c:29:
>> /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/ pyconfig.h:803:1: >> warning: this is the location of the previous definition >> gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup >> build/temp.macosx-10.6-universal-2.6/_mysql.o -L/usr/local/mysql/lib >> -lmysqlclient_r -lz -lm -lmygcc -o >> build/lib.macosx-10.6-universal-2.6/_mysql.so -arch x86_64
>> Graham
>> On 25 August 2011 02:07, Jianbao Tao <jianbao....@gmail.com> wrote: >> > I tried all the 'otool -L' suggestions, but nothing stand out compared >> > to >> > previous results. >> > Here is what I got from 'otool -l', which I have no clue what these >> > lines >> > mean: >> >>$ otool -l
I prefer a virtual environment without site-packages from the local system. So, building MySQL-python from the source code again doesn't give me much help. I also tried the alternative within the virtual environment, but as you suspected, it didn't work. Anyway, I want to move on from this problem for now. Maybe some day a solution will come around.
However, I want to show my gratitude to you, Graham. Thank you so much for helping me with this one. I did learn a lot how to troubleshoot this kind of issues. Like the 'file' and 'otool' commands, I have never used them before, and didn't even know they are around.
Best regards, Jianbao
On Wed, Aug 24, 2011 at 9:29 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote: > On 25 August 2011 13:19, Jianbao Tao <jianbao....@gmail.com> wrote: > > Thank you, Graham. > > I installed MySQL-python inside the virtual environment created by > > virtualenv with > > <shell> > >>$ pip install MySQL-python
> That could well be the problem. If mysql_config is not found when pip > is running to do install it will not be able to link library properly. > Looking in the code it does:
> So, mysql_config must have failed and so couldn't be sure that could > use mysqlclient_r and used mysqlclient instead.
> Further, because it didn't know where libs were, couldn't embed the > proper library path to find library. Then at run time it isn't finding > it or isn't liking it.
> > </shell> > > So, I don't really know what configuration pip used. I think I also built > > MySQL-python from the source code before, but that didn't work out > either.
> Would still recommend you go back and try that and set PATH to include > bin directory were mysql_config is located like I showed I did. Check > with otool of _mysql.so in the build directory before installing it in > virtual environment.
> to try to ensure pip can find mysql_config. This may no work depending > on whether pip cleans the user environment before doing stuff.
> Graham
> > Jianbao
> > On Wed, Aug 24, 2011 at 8:35 PM, Graham Dumpleton > > <graham.dumple...@gmail.com> wrote:
> >> Do you remember what you did when you build the MySQL-python package > >> in the first place?
> >> Did you explicitly put MySQL bin directory in PATH or did you modify > >> the site.cfg file to say where it was?
> >> Did you modify any of the default settings in site.cfg?
> >> If you rebuilt it multiple times or have upgraded MySQL, did you start > >> over building Python package from a clean source package and not one > >> with existing build/dist directories present?
> >> If you still have the source package and haven't cleaned it, what do > >> you get for:
> >> $ otool -L build/lib.macosx-10.6-universal-2.6/_mysql.so > >> build/lib.macosx-10.6-universal-2.6/_mysql.so: > >> /usr/local/mysql/lib/libmysqlclient_r.16.dylib (compatibility > >> version > >> 17.0.0, current version 17.0.0) > >> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version > >> 1.2.3) > >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > >> version 125.2.10)
> >> in the source package.
> >> Right now thinking something went wrong with the original build.
> >> Not only aren't you using the reentrant MySQL library, but no full > >> path encoded for it.
> >> Perhaps go back to fresh MySQL-python package and build again and show > >> us the steps you did and the output as shown below as an example. Most > >> interested to see the final link line, which for me is:
On 25 August 2011 14:47, Jianbao Tao <jianbao....@gmail.com> wrote:
> I prefer a virtual environment without site-packages from the local system. > So, building MySQL-python from the source code again doesn't give me much > help.
What??????
There is nothing stopping you from installing MySQL-python from source code into a virtual environment.
Care to explain why that doesn't work.
$ virtualenv --no-site-packages /tmp/myvirtualenv New python executable in /tmp/myvirtualenv/bin/python Installing setuptools............done.
$ source /tmp/myvirtualenv/bin/activate
(myvirtualenv)$
Output from both setup.py and pip below. Both work.
At this point since not even actually showing the output from your builds though, one can only gaze into the crystal ball and wonder.
$ PATH=/usr/local/mysql/bin:$PATH python setup.py install running install running bdist_egg running egg_info writing MySQL_python.egg-info/PKG-INFO writing top-level names to MySQL_python.egg-info/top_level.txt writing dependency_links to MySQL_python.egg-info/dependency_links.txt reading manifest file 'MySQL_python.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no files found matching 'MANIFEST' warning: no files found matching 'ChangeLog' warning: no files found matching 'GPL' writing manifest file 'MySQL_python.egg-info/SOURCES.txt' installing library code to build/bdist.macosx-10.6-universal/egg running install_lib running build_py creating build creating build/lib.macosx-10.6-universal-2.6 copying _mysql_exceptions.py -> build/lib.macosx-10.6-universal-2.6 creating build/lib.macosx-10.6-universal-2.6/MySQLdb copying MySQLdb/__init__.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb copying MySQLdb/converters.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb copying MySQLdb/connections.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb copying MySQLdb/cursors.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb copying MySQLdb/release.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb copying MySQLdb/times.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb creating build/lib.macosx-10.6-universal-2.6/MySQLdb/constants copying MySQLdb/constants/__init__.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb/constants copying MySQLdb/constants/CR.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb/constants copying MySQLdb/constants/FIELD_TYPE.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb/constants copying MySQLdb/constants/ER.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb/constants copying MySQLdb/constants/FLAG.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb/constants copying MySQLdb/constants/REFRESH.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb/constants copying MySQLdb/constants/CLIENT.py -> build/lib.macosx-10.6-universal-2.6/MySQLdb/constants running build_ext building '_mysql' extension creating build/temp.macosx-10.6-universal-2.6 gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -pipe -Dversion_info=(1,2,3,'final',0) -D__version__=1.2.3 -I/usr/local/mysql/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2. 6 -c _mysql.c -o build/temp.macosx-10.6-universal-2.6/_mysql.o -g -Os -arch x86_64 -fno-common -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL In file included from _mysql.c:36: /usr/local/mysql/include/my_config.h:1069:1: warning: "HAVE_WCSCOLL" redefined In file included from /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/ Python.h:8, from pymemcompat.h:10, from _mysql.c:29: /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/ pyconfig.h:803:1: warning: this is the location of the previous definition gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup build/temp.macosx-10.6-universal-2.6/_mysql.o -L/usr/local/mysql/lib -lmysqlclient_r -lz -lm -lmygcc -o build/lib.macosx-10.6-universal-2.6/_mysql.so -arch x86_64 creating build/bdist.macosx-10.6-universal creating build/bdist.macosx-10.6-universal/egg copying build/lib.macosx-10.6-universal-2.6/_mysql.so -> build/bdist.macosx-10.6-universal/egg copying build/lib.macosx-10.6-universal-2.6/_mysql_exceptions.py -> build/bdist.macosx-10.6-universal/egg creating build/bdist.macosx-10.6-universal/egg/MySQLdb copying build/lib.macosx-10.6-universal-2.6/MySQLdb/__init__.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb copying build/lib.macosx-10.6-universal-2.6/MySQLdb/connections.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb creating build/bdist.macosx-10.6-universal/egg/MySQLdb/constants copying build/lib.macosx-10.6-universal-2.6/MySQLdb/constants/__init__.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb/constants copying build/lib.macosx-10.6-universal-2.6/MySQLdb/constants/CLIENT.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb/constants copying build/lib.macosx-10.6-universal-2.6/MySQLdb/constants/CR.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb/constants copying build/lib.macosx-10.6-universal-2.6/MySQLdb/constants/ER.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb/constants copying build/lib.macosx-10.6-universal-2.6/MySQLdb/constants/FIELD_TYPE.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb/constants copying build/lib.macosx-10.6-universal-2.6/MySQLdb/constants/FLAG.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb/constants copying build/lib.macosx-10.6-universal-2.6/MySQLdb/constants/REFRESH.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb/constants copying build/lib.macosx-10.6-universal-2.6/MySQLdb/converters.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb copying build/lib.macosx-10.6-universal-2.6/MySQLdb/cursors.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb copying build/lib.macosx-10.6-universal-2.6/MySQLdb/release.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb copying build/lib.macosx-10.6-universal-2.6/MySQLdb/times.py -> build/bdist.macosx-10.6-universal/egg/MySQLdb byte-compiling build/bdist.macosx-10.6-universal/egg/_mysql_exceptions.py to _mysql_exceptions.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/__init__.py to __init__.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/connections.py to connections.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/constants/__init__.py to __init__.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/constants/CLIENT.py to CLIENT.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/constants/CR.py to CR.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/constants/ER.py to ER.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/constants/FIELD_TYPE.py to FIELD_TYPE.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/constants/FLAG.py to FLAG.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/constants/REFRESH.py to REFRESH.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/converters.py to converters.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/cursors.py to cursors.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/release.py to release.pyc byte-compiling build/bdist.macosx-10.6-universal/egg/MySQLdb/times.py to times.pyc creating stub loader for _mysql.so byte-compiling build/bdist.macosx-10.6-universal/egg/_mysql.py to _mysql.pyc creating build/bdist.macosx-10.6-universal/egg/EGG-INFO copying MySQL_python.egg-info/PKG-INFO -> build/bdist.macosx-10.6-universal/egg/EGG-INFO copying MySQL_python.egg-info/SOURCES.txt -> build/bdist.macosx-10.6-universal/egg/EGG-INFO copying MySQL_python.egg-info/dependency_links.txt -> build/bdist.macosx-10.6-universal/egg/EGG-INFO copying MySQL_python.egg-info/top_level.txt -> build/bdist.macosx-10.6-universal/egg/EGG-INFO writing build/bdist.macosx-10.6-universal/egg/EGG-INFO/native_libs.txt zip_safe flag not set; analyzing archive contents... creating dist creating 'dist/MySQL_python-1.2.3-py2.6-macosx-10.6-universal.egg' and adding 'build/bdist.macosx-10.6-universal/egg' to it removing 'build/bdist.macosx-10.6-universal/egg' (and everything under it) Processing MySQL_python-1.2.3-py2.6-macosx-10.6-universal.egg Removing /private/tmp/myvirtualenv/lib/python2.6/site-packages/MySQL_python-1.2.3-py 2.6-macosx-10.6-universal.egg Copying MySQL_python-1.2.3-py2.6-macosx-10.6-universal.egg to /private/tmp/myvirtualenv/lib/python2.6/site-packages MySQL-python 1.2.3 is already the active version in easy-install.pth
Installed /private/tmp/myvirtualenv/lib/python2.6/site-packages/MySQL_python-1.2.3-py 2.6-macosx-10.6-universal.egg Processing dependencies for MySQL-python==1.2.3 Finished processing dependencies for MySQL-python==1.2.3
Now pip.
$ PATH=/usr/local/mysql/bin:$PATH pip install MySQL-python Downloading/unpacking MySQL-python Running setup.py egg_info for package MySQL-python warning: no files found matching 'MANIFEST' warning: no files found matching 'ChangeLog' warning: no files found matching 'GPL' Installing collected packages: MySQL-python Running setup.py install for MySQL-python building '_mysql' extension gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -pipe -Dversion_info=(1,2,3,'final',0) -D__version__=1.2.3 -I/usr/local/mysql/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2. 6 -c _mysql.c -o build/temp.macosx-10.6-universal-2.6/_mysql.o -g -Os -arch x86_64 -fno-common -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL In file included from _mysql.c:36: /usr/local/mysql/include/my_config.h:1069:1: warning: "HAVE_WCSCOLL" redefined In file included from /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/ Python.h:8, from pymemcompat.h:10,
