I am attempting to set up my Django virtualenv production environment on a Linux shared host server. Installing python packages using pip goes fine until I try to install Mysql-Python, which crashes. Does anyone know why this is failing? Looking through the error log, I think it's an architecture incompatibility between the package and my python installation because of these lines:
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: warning: i386 architecture of input file build/temp.linux-x86_64-2.4/_mysql.o' is > incompatible with i386:x86-64 output build/temp.linux-x86_64-2.4/_mysql.o: In function _mysql_field_to_python':
I was told the server is 64-bit and is running Python 2.4, although I'm not sure how to double-check the former. Ive been googling this issue for several hours but I've only found references to install/import errors on macs. I'm thinking perhaps I need to compile a different version of MySQLdb instead of just doing pip install -E myvirtualenv MySQL-python but I'm unsure. Any help is greatly appreciated.
If you can't get the same architecture through pip or your package manager, you will probably need to either recompile Python (which you might consider anyway -- Python 2.4 is old), or MySQLdb.
Unfortunately, a lot of Python libraries are not cross-compatible between i386 and x86_64 -- I've actually had exactly the same issue with HGSubversion (the actual issue was with subvertpy, but I needed that for hgsubversion) and cx_Oracle. My solution was to downgrade Python to 2.6 for i386. Stunk.
Related
I am trying to install PyVlFeat and the installation is failing with exactly this issue mentioned here.
pyvlfeat error during installation: /usr/bin/ld: cannot find -lboost_python-mt-py26
As per the answer mentioned there, I need to change the reference of "-lboost_python-mt-py26" to the correct version of Boost Python I have on my system.
I am on ubuntu 14.04 and I tried to detect the version of my boost python by using this command "ls /usr/lib/libboost_python*"
I don't seem to have any libraries with a similar name there. However, I have installed Boost Python using this command "sudo apt-get install libboost-all-dev" as mentioned here.
https://stackoverflow.com/questions/25891667/boost-undefined-reference-ubuntu-14-04-boost-1-54
Since Boost Python is already there, how should I use it correctly to compile PyVlFeat.
The -mt suffix had been removed from Boost Libraries. The installed Boost libraries are multi-threading safe.
Changing the reference to "-lboost_python-py27" (Removing -mt suffix and using proper version of python will solve the problem.
I am trying to install py2cairo on a framework build (Mac OSX Lion) of python 2.7.3 using brew. I have been unsuccessful this far.
First, I tried a simple
brew install py2cairo
This seems to work only on a non-framework build of python. When I do this on my framework build python faults as soon as I import cairo with an incompatible binary error.
Second, I have tried to build it myself by grabbing it from github and issuing:
python waf configure
This fails with:
Checking for library python2.7 : not found
Checking for library python2.7 : not found
Checking for library python2.7 : not found
Checking for library python27 : not found
Checking for program python2.7-config : /usr/local/Cellar/python/2.7.3/bin/python2.7- config
Checking for header Python.h : Could not find the python development headers
The configuration failed
(complete log in /Users/tobin/tmp/py2cairo/build_directory/config.log)
I have tried everything at: How to install PyCairo 1.10 on Mac OSX with default python but none of this has helped.
It appears to me that this may be failing to find python2.7 library and header file since it is a framework build. Is that possible? I was looking at the brew formula and it appears that framework builds do not get --enable-share set at build time. I'm not sure if that is relevant here - but maybe one possibility.
Anyone other insights would be great. Thanks in advance.
UPDATE:
I discovered that the inability to build py2cairo had to do with the use of the "-march=native" flag by gcc. gcc (4.2.1) on Mac OSX has issues with this. I then reinstalled gcc as well as python. Afterwards when building py2cairo with waf - it was getting "-march=core2" and everything built.
Unfortunately, not all is good yet. I get the same error when I import cairo from my build that I got from the brew version (as mentioned above). The exact error message is:
>>> import cairo
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap: 6
and then python exits.
It would now seem that the issue is related to the framework build of python. I tested it without a framework build and it worked fine.
So as to not leave this question dangling ... I wanted to follow up with my resolution and learning points:
As noted above there was an incompatibility with my version of OSX and a gcc compile flag called -march=native. In a later version it was coming up as -march=core2. This pretty much fixed itself with compiler/version changes after cleaning up my machine.
For years I have had quite a mess with all of my various MAC OSX installs - and accepting the "migration option". Two machines ago - I installed the python binaries for versions 2.4, and 2.5, Then eventually went to macports for various reasons. Then eventually went to homebrew. When I went to homebrew I tried to clean things up by hand (but of course this can be challenging). To make matters worse - everytime I have gotten a new mac (2 times) in the last 6 years I take "the migration install" option and this pushes the mess forward and makes it worse. So as I started looking into things further - I had various installs of python, with different versions - mac-native, python-native, mac ports, homebrew, and probably even others too on my system. So my best guess is that cairo was somehow finding one of these and trying to build against it.
I finally solved this by deleting a bunch of old python installs by hand and then starting over with a fresh virtualenv and homebrew install of python 2.7.
WARNING: I don't think that this is the smartest way to go. I was careful not to delete a version of Python that I thought came native with OSX Lion (I think it is 2.6) - but it is not clear how it may potentially effect some other things that may have depended on older mac installs of python. I ended up deleting a 2.3, a 2.4, and two different 2.5s - along with various links in some places. WHAT A MESS! Unless you are absolutely sure of what it is you are doing (which I was not) I would not suggest this approach. I was basically trying to kill 6 years of python install crud that has collected.
To be safe I probably should have started with a fresh OSX Lion install and then added my homebrew version and went from there. I will likely do this in the near future.
I installed everything successfully, or so I thought:
MySQL 5.5 for x86_64.
Python 2.7, x86_64.
mysql-python 1.2.3, x86_64.
But when I try:
import MySQLdb
I get:
ImportError:
dlopen(/Users/aj/.python-eggs/MySQL_python-1.2.3-py2.7-macosx-10.6-ix86_64.egg-tmp/_mysql.so, 2):
no suitable image found.
Did find:
/Users/aj/.python-eggs/MySQL_python-1.2.3-py2.7-macosx-10.6-ix86_64.egg-tmp/_mysql.so: mach-o,
but wrong architecture
What else can I be missing?
My system is of course 64bit version as well, uname -a gives:
Darwin ajmacbook.local 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; root:xnu-1699.22.81~1/RELEASE_X86_64 x86_64
I think I have read most SO answers and Google results on the subject, can't think of anything else to try. Any suggestion would be appreciated.
I think there might be slight quirks with doing this on Mac 64-bit (and if you google this problem shows up a lot too).
I've run into it, and there are a couple things you can do:
Override the environment
You can change the DYLD_LIBRARY_PATH environment variable, which tells the linker where to look for dynamic libraries (.so files and such). You said you also downloaded the 64-bit version of MySQL, so where ever it's installed, change the path you see here:
In a shell:
export DYLD_LIBRARY_PATH=/usr/local/mysql/lib/
And then run python and see if you can import MySQLdb.
If that works, you can make this permanent by altering your shell profile (.bash_profile, most likely).
Use homebrew
I don't really like mucking around with making sure MySQL and Python and all that are correct architectures and installing them separately. I run homebrew, which is a sort of package manager for Mac. If you install that, you can pretty easily take care of this issue:
brew install python
brew install mysql
/usr/local/share/python/easy_install mysql-python
Do note that homebrew installs into /usr/local, so you should add /usr/local/bin to your PATH, ahead of /usr/bin and /bin, otherwise you'll get really confused why python is different.
You can add /usr/local/share/python to your PATH as well, to make it permanent.
With the help of the comment from #birryree I found the problem. I would probably be better off following the procedure suggested by #birryree in his answer but I did try this before and it worked:
As suggested, I did:
file /Users/aj/.python-eggs/MySQL_python-1.2.3-py2.7-macosx-10.6-ix86_64.egg-tmp/_mysql.so
To get: [...]: Mach-O bundle i386
So, wrong architecture. From there I did the same with mysql and python just to be sure:
file $(which python) gave:
/Library/Frameworks/Python.framework/Versions/2.7/bin/python: Mach-O universal binary with 2 architectures
/Library/Frameworks/Python.framework/Versions/2.7/bin/python (for architecture i386): Mach-O executable i386
/Library/Frameworks/Python.framework/Versions/2.7/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64
And file $(which mysql):
/usr/local/mysql/bin/mysql: Mach-O 64-bit executable x86_64
So I uninstalled the mysql-python package: sudo pip uninstall mysql-python and installed it again. But doing this I realized my previous mistake while installing this package. First time I typed:
sudo ARCHFLAGS='-arch ix86_64' python setup.py build (and "install" afterwards)
The architecture name was wrong, should be '-arch x86_64', no "i", so it just ignored my flag and installed the 32bit.
The proper commands to install the downloaded mysql-python package for 64bit (from the source folder):
sudo ARCHFLAGS='-arch x86_64' python setup.py build
sudo ARCHFLAGS='-arch x86_64' python setup.py install
VERY IMPORTANT!
As mentioned above, please make sure you are running the 64-bit version of mysql. It's easy to overlook this detail especially if you've upgraded from Snow Leopard. (I certainly did).
if you're not sure about removing the older version of mysql on your system, refer to this post: http://johnmcostaiii.net/2011/removing-mysql-osx-lion/
I had the same problem, and a lot of headache with MySQLdb after fixing the 64bit issue (it was complaining also about where is libmysqlclient.18.dylib).
I think it's time to switch to the official MysQL Python Connector?
sudo pip install mysql-connector-python
Or download it from: http://dev.mysql.com/downloads/connector/python/
Documentation: http://dev.mysql.com/doc/refman/5.5/en/connector-python.htm
It's easy to use and also compatible with PEP 249 (Python DB API version 2.0).
Also make sure you are running Python 64-bit too. I was running mysql 64 bit and Python 32bit so got the 'but wrong architecture' error
i am trying to install pygtk on my mac which then asked me to install pygobject which then asked me to get gobject-introspection . the problem i have in this installation is while configuring it shows this error :
checking for FFI... no
checking for ffi.h... configure: error: ffi.h not found
please do help me with this as i need to get gtk .
/usr/include/ffi->location of ffi.h
thanks in advance
Try this:
export FFI_CFLAGS=/usr/include
export FFI_LIBS=/usr/lib
then
./configure
I hope this solves your problem.
I initially found this compile failure while assembling GLib (all versions I tried that were more recent than 2.28.7), but I again encountered it with gobject; and it appears related to several other packages' build failures:
http://lists.gnu.org/archive/html/guile-gtk-general/2006-10/msg00010.html
Weird error when installing GLIB
http://lists.freebsd.org/pipermail/freebsd-gnome/2011-August/026346.html
I tried following the advice provided in all of these threads (as the solutions discussed are largely the same) with no success.
The Final Solution: a complete recompile and install of GCC (4.7.2)
Why did compiling GCC (4.7.2) solve the issue?
I found this post in the Debian Bug Archive: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523869
While reading, I noted that my system was using an affected version of GCC to compile my various sources (from an FC9 installation on a relic laptop).
I chose 4.7.2 as my goal because it was, at the time of this writing, the most current build in the stable tree. I'm relatively sure that a simple package install of a recent GCC on your system will yield the same results (so long as you get 4.3.5-4 or later), but I haven't tested this as there are understandably no such packages for an FC9 install. The package route has many potential positive aspects beyond being easy, please read below..
Important Note: If you are trying to compile GCC, you'll probably need a working (and current) glibc enviroment... Please read up on this complication BEFORE you start the manual process: http://cygwin.com/ml/libc-alpha/2012-02/msg00646.html
The workaround is to find a Glibc version that predates the commit noted in the article above (i went with 2.14), compile GCC 4.5 with that installed (i chose 4.5.3 due to release proximity with glibc 2.14), and then start the process again with current Glibc and GCC... best of luck!
GCC: http://ftp.gnu.org/gnu/gcc/
Glibc: http://ftp.gnu.org/gnu/glibc/
Binutils: http://ftp.gnu.org/gnu/binutils/
ffi.h is provided by the package libffi-dev, which is actually from the gcc source package. and most probably it's available for linux.
ive had this issue with PIL and reportlab so far. the issue is that the install fails with
error: command 'gcc-4.2' failed with exit status 1
i've found a fix, in this document paikialog
question is,
why does the
ARCHFLAGS="-arch i386 -arch x86_64"
fix the issue?
whats it doing?
and how can i force that globally so i dont have to use it every time i try to add a module that needs compiling?
The explanation is here. You could avoid the problem by installing Xcode 3 instead of Xcode 4. Or, better, you can avoid the problem by installing another Python instance that does not include the PPC arch; a good choice is the current Python 2.7.2 64-/32-bit installer from python.org.
I suggest using MacPorts which allows the simple installation of almost all available python libraries.