I'm experiencing a problem with matplotlib, to be more precise with pyplot.
Just after installing, doing
import matplotlib.pyplot
gives me this error:
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so, 2): Symbol not found: _png_create_info_struct
Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so
Expected in: flat namespace
in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so
So I have no idea what is going on. I'm on Mac OS X 10.6, I have installed python2.7 from disk image and matplotlib from the terminal by using the tar.gz and doing the usual
python setup.py build
python setup.py install
When the installation starts I see:
BUILDING MATPLOTLIB
matplotlib: 1.1.0
python: 2.7 (r27:82508, Jul 3 2010, 21:12:11) [GCC 4.0.1
(Apple Inc. build 5493)]
platform: darwin
REQUIRED DEPENDENCIES
numpy: 1.6.1
freetype2: 10.0.4
OPTIONAL BACKEND DEPENDENCIES
libpng: 1.2.44
Tkinter: no
* TKAgg requires Tkinter
Gtk+: no
* Building for Gtk+ requires pygtk; you must be able
* to "import gtk" in your build/install environment
Mac OS X native: yes
Qt: no
Qt4: no
Cairo: no
OPTIONAL DATE/TIMEZONE DEPENDENCIES
datetime: present, version unknown
dateutil: matplotlib will provide
pytz: matplotlib will provide
adding pytz
OPTIONAL USETEX DEPENDENCIES
dvipng: 1.13
ghostscript: 8.61
latex: 3.1415926
Any help guys please!
Cheers
http://fonnesbeck.github.io/ScipySuperpack/
I've been fighting this same problem and the answer was to install the ScipySuperpack. The problem (at least for me) was that I have a 64 bit version of Python, and the version of matplotlib I was pulling from github was 32 bit. I cloned the ScipySuperpack repository and ran the setup script and it worked.
No amount of fighting with brew or ports was getting me anywhere.
In case anyone has the same problem as me and finds this thread, here is how I solved it.
First, I follow the current matplotlib README.osx, along with this guy's advice (not sure if that's necessary)...
brew install freetype --universal
brew install libpng --universal
export CPPFLAGS="-I/usr/local/opt/libpng/include -I/usr/local/opt/freetype/include"
export LDFLAGS=" -L/usr/local/opt/libpng/lib -L/usr/local/opt/freetype/lib"
I also set those variables as recommended by brew.
Then, I did the following
(running from matplotlib build directory, after having built and installed)
drigz#mbp matplotlib 0$ find . -name _png.so
./build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
drigz#mbp matplotlib 0$ otool -L ./build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
./build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so:
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 830.0.0)
No libpng! A bad sign... let's see the build output again...
drigz#mbp matplotlib 0$ rm ./build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
drigz#mbp matplotlib 0$ python setup.py build
[SNIP]
c++ -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -isysroot /Developer/SDKs/MacOSX10.6.sdk -g -L/usr/local/opt/libpng/lib -L/usr/local/opt/freetype/lib -I/usr/local/opt/libpng/include -I/usr/local/opt/freetype/include build/temp.macosx-10.6-intel-2.7/src/_png.o build/temp.macosx-10.6-intel-2.7/src/mplutils.o build/temp.macosx-10.6-intel-2.7/CXX/cxx_extensions.o build/temp.macosx-10.6-intel-2.7/CXX/cxxsupport.o build/temp.macosx-10.6-intel-2.7/CXX/IndirectPythonInterface.o build/temp.macosx-10.6-intel-2.7/CXX/cxxextensions.o -L/sw/lib -L/usr/local/lib -L/usr/lib -L/usr/X11/lib -lpng14 -lz -lstdc++ -lm -o build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
ld: warning: in /sw/lib/libpng14.dylib, file was built for i386 which is not the architecture being linked (x86_64)
It's not using the right libpng: what does brew provide?
drigz#mbp matplotlib 0$ echo $LDFLAGS
-L/usr/local/opt/libpng/lib -L/usr/local/opt/freetype/lib
drigz#mbp matplotlib 0$ ls /usr/local/opt/libpng/lib
libpng.a libpng.la libpng15.a pkgconfig
libpng.dylib libpng15.15.dylib libpng15.dylib
Let's try to fix that by copy-pasting the command but changing -lpng14 to -lpng15... (there's probably a better way to stop it from using the wrong one, but this worked)
drigz#mbp matplotlib 0$ c++ -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -isysroot /Developer/SDKs/MacOSX10.6.sdk -g -L/usr/local/opt/libpng/lib -L/usr/local/opt/freetype/lib -I/usr/local/opt/libpng/include -I/usr/local/opt/freetype/include build/temp.macosx-10.6-intel-2.7/src/_png.o build/temp.macosx-10.6-intel-2.7/src/mplutils.o build/temp.macosx-10.6-intel-2.7/CXX/cxx_extensions.o build/temp.macosx-10.6-intel-2.7/CXX/cxxsupport.o build/temp.macosx-10.6-intel-2.7/CXX/IndirectPythonInterface.o build/temp.macosx-10.6-intel-2.7/CXX/cxxextensions.o -L/sw/lib -L/usr/local/lib -L/usr/lib -L/usr/X11/lib -lpng15 -lz -lstdc++ -lm -o build/lib.macosx-10.6-intel-2.7/matplotlib/_png.so
drigz#mbp matplotlib 0$ python setup.py install
[SNIP]
drigz#mbp matplotlib 0$ otool -L /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/_png.so:
/usr/local/opt/libpng/lib/libpng15.15.dylib (compatibility version 29.0.0, current version 29.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 830.0.0)
I just wanted to add a few suggestions for people who might still be having trouble. I've been searching around for a while and trying lots of different things. Ultimately, it was one of the following that allowed me to import matplotlib.pyplot on Python 2.7.6 on OSX 10.6 (with X11 and XQuartz installed previously, perhaps outdated):
Installing pkg-info
brew install pkg-info
Installing libpng from source to /usr/local/lib (configure --libdir=/usr/local)
Installing XQuartz for Mac
Deleting matplotlib folders from site-packages (probably old, failed attempts).
Running
ln -s /usr/local/opt/freetype/include/freetype2 /usr/local/include/freetype
Finally,
port install py27-matplotlib
installed it, and I was able to import. The original error I had was
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.6-x86_64.egg/matplotlib/_png.so, 2): Library not loaded: /opt/local/lib/libpng15.15.dylib
Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.6-x86_64.egg/matplotlib/_png.so Reason: image not found
Though some attempts ran into this error:
In file included from src/ft2font.cpp:3:
In file included from src/ft2font.h:16:
/usr/X11/include/ft2build.h:56:10: fatal error: 'freetype/config/ftheader.h' file not found
#include <freetype/config/ftheader.h>
I'm sorry I can't be more specific.
You should follow these directions for installing Matplotlib from source on OSX: https://github.com/matplotlib/matplotlib/blob/master/README.osx
OSX is a bit messy with the lib files, but following the directions from the link should resolve any issues you're having as it automatically installs the dependencies in a self-contained manner.
I had same problem as OP. I git cloned the repo and "python setup install" instead of pre-compiled version. Took about 20 minutes to compile and seems to work now.
Related
I'm trying to install Python 3.11.1 via pyenv. I keep encoutnering this error message:
> pyenv install 3.11.1
...
Installing Python-3.11.1...
python-build: use zlib from xcode sdk
BUILD FAILED (OS X 13.1 using python-build 20180424)
...
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I tried adding extra flags as indicated in here but to no avail:
> brew install gettext
> export LDFLAGS="-L/opt/homebrew/lib"; export CPPFLAGS="-I/opt/homebrew/include"
Here are my version info:
OS: macOS 13.1
Pyenv: v. 2.3.12
> brew config
HOMEBREW_VERSION: 3.6.20
ORIGIN: https://github.com/Homebrew/brew
HEAD: 344d32bf7f40183359592ef81ca6486e0587981b
Last commit: 3 weeks ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 28bf73728557db3dd308f92177b3556deedbeafd
Core tap last commit: 32 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.9NEo145z0J/org.macosforge.xquartz:0
HOMEBREW_MAKE_JOBS: 10
Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: 10-core 64-bit arm_firestorm_icestorm
Clang: 14.0.0 build 1400
Git: 2.37.1 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.85.0 => /usr/bin/curl
macOS: 13.1-arm64
CLT: 14.2.0.0.1.1668646533
Xcode: 14.2
Rosetta 2: false
I have the following problem,
I'm building a python module using swig to wrap C-code.
I have installed python, gcc(45),.. using MacPorts.
Here's a minimal setup which reproduces the problem:
Two files:
test.i:
%module test
double sum(double a, double b);
test.c:
double sum(double a, double b){return a+b;}
I run
$ swig -python -I. test.i
$ gcc -fPIC -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c test_wrap.c
$ gcc -c -o test.o test.c
$ gcc -shared -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -lpython -dynamiclib -fPIC -o _test.so test.o test_wrap.o
When I run python (the MacPorts one: /opt/local/bin/python2.7) and try to import the module via import test, the code crashes with exactly the same problem as above.
Examining the file _test.so with otool yields the following:
$ otool -L _test.so
_test.so:
_test.so (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.2)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)
/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
I found out that in the swig-generated file test.py the line #include <Python.h> is contained. However there is a Python.h in /System/Library/... and one in /opt/local/...
My guess is that the mistake is happening here. But how can I make the compiler/linker point to the correct one?
Thanks a lot for any help!!
Thomas
I don't have a mac, but I have good results by using distutils to deal with multiple Python versions on Linux and Windows when using swig (swig doc and distutil doc). The following shows a minimal example of a setup.py:
from distutils.core import setup,Extension
ext = Extension('_test',sources=['test.c,test.i'])
setup(name='test',ext_modules=[ext],py_modules=["test"])
Distutils is binding to the calling python version and knows about swig. However, it is important to compile by:
python setup.py build_ext
python setup.py build_py
And not calling build directly.
I'm trying to get the python-sybase module working on OSX 10.6, but I've run into a bit of a snag.
When I do
import Sybase
I get
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "Sybase.py", line 15, in <module>
from sybasect import *
ImportError: dlopen(/Library/Python/2.6/site-packages/python_sybase-0.40pre2-py2.6-macosx-10.6-universal.egg/sybasect.so, 2): Symbol not found: _blk_alloc
Referenced from: /Library/Python/2.6/site-packages/python_sybase-0.40pre2-py2.6-macosx-10.6-universal.egg/sybasect.so
Expected in: flat namespace
in /Library/Python/2.6/site-packages/python_sybase-0.40pre2-py2.6-macosx-10.6-universal.egg/sybasect.so
I took a look at sybasect.so, and sure enough, _blk_alloc is undefined. The function is located in Sybase's sybblk.dylib, which is installed, and its containing directory is in LD_LIBRARY_PATH.
When I compiled python-sybase using python setup.py build, the gcc command appears to find all of the right libs correctly, but for some reason those libs don't appear to be linked after installing sybasect.so to the Python module dir.
The gcc command is
gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc -arch x86_64 build/temp.macosx-10.6-universal-2.6/blk.o build/temp.macosx-10.6-universal-2.6/databuf.o build/temp.macosx-10.6-universal-2.6/cmd.o build/temp.macosx-10.6-universal-2.6/conn.o build/temp.macosx-10.6-universal-2.6/ctx.o build/temp.macosx-10.6-universal-2.6/datafmt.o build/temp.macosx-10.6-universal-2.6/iodesc.o build/temp.macosx-10.6-universal-2.6/locale.o build/temp.macosx-10.6-universal-2.6/msgs.o build/temp.macosx-10.6-universal-2.6/numeric.o build/temp.macosx-10.6-universal-2.6/money.o build/temp.macosx-10.6-universal-2.6/datetime.o build/temp.macosx-10.6-universal-2.6/date.o build/temp.macosx-10.6-universal-2.6/sybasect.o -L/Applications/Sybase/System/OCS-15_0/lib -lsybblk -lsybct -lsybcs -lsybtcl -lsybcomn -lsybintl -lsybunic -o build/lib.macosx-10.6-universal-2.6/sybasect.so
The -L/Applications/Sybase/System/OCS-15_0/lib location is correct, and that folder contains all of the right .dylib's.
When I run otool the output is:
$ otool -L build/lib.macosx-10.6-universal-2.6/sybasect.so
build/lib.macosx-10.6-universal-2.6/sybasect.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
I was expecting to see the Sybase libs in there.
I'm a little new to linking on Mac. How do I ensure that sybasect.so references the Sybase libs?
Fixed it.
The problem was that the various Sybase libraries I was linking to were 32-bit only, but I was running Python in 64 bit mode. The fix was just running python in 32-bit mode.
I used the command defaults write com.apple.versioner.python Prefer-32-Bit -bool yes since I don't have any particular need for 64 bit mode.
I'm trying install pycrypto on osx with easy_install and I'm getting the following error:
easy_install pycrypto
Searching for pycrypto
Reading http://pypi.python.org/simple/pycrypto/
Reading http://pycrypto.sourceforge.net
Reading http://www.pycrypto.org/
Reading http://www.amk.ca/python/code/crypto
Best match: pycrypto 2.3
Downloading http://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.3.tar.gz
Processing pycrypto-2.3.tar.gz
Running pycrypto-2.3/setup.py -q bdist_egg --dist-dir /var/folders/3D/3D07iptvHZuzuYaeQDMFIU+++TI/-Tmp-/easy_install-00HgRU/pycrypto-2.3/egg-dist-tmp-BWGYsg
warning: GMP library not found; Not building Crypto.PublicKey._fastmath.
/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler (/usr/bin/../libexec/gcc/darwin/ppc/as or /usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed
Installed assemblers are:
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
src/MD2.c:134: fatal error: error writing to -: Broken pipe
compilation terminated.
lipo: can't open input file: /var/folders/3D/3D07iptvHZuzuYaeQDMFIU+++TI/-Tmp-//ccoXuPRo.out (No such file or directory)
error: Setup script exited with error: command 'gcc-4.2' failed with exit status 1
I have this in my ~/.bash_profile to address this very issue:
# Set compile flags to not try to compile for PPC (no longer supported by xcode 4)
# (this is required for eg building pycrypto)
export ARCHFLAGS="-arch i386 -arch x86_64"
Yes, it's a result of installing Xcode 4. It tries to build for ppc, although Xcode 4 no longer has the relevant bits for that. See this question for ways round it: https://superuser.com/questions/259278/python-2-6-1-pycrypto-2-3-pypi-package-broken-pipe-during-build
xCode 5.1
ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future pip install pycrypto
Looks like this got a little more difficult with OSX 10.9. Here's the additional stuff I did:
brew install libffi
If you see the warning about how it's installed "keg-only", that means homebrew did not link it, so you'll need to provide some more info with export PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig. At that point the install blows up because by default OSX now dies on warning flags, so suppress that behavior as well:
export CFLAGS=-Qunused-arguments
export CPPFLAGS=-Qunused-arguments
Then you should be able to install with pip.
I'm trying to run mod_wsgi 3.1 under Apache 2.2.14 using a non-default python installation on Mac OS X 10.6.
After downloading the mod_wsgi source I run:
sudo apachectl -k stop
then
./configure --with-python=/usr/local/Cellar/python/2.6.4/bin/python
make
sudo make install
I then start up apache again
sudo apachectl -k start
When I cat /var/log/httpd/error_log I see:
[Mon Dec 21 12:27:26 2009] [warn] mod_wsgi: Compiled for Python/2.6.4.
[Mon Dec 21 12:27:26 2009] [warn] mod_wsgi: Runtime using Python/2.6.1.
[Mon Dec 21 12:27:26 2009] [notice] Apache/2.2.14 (Unix) DAV/2 mod_wsgi/3.1 Python/2.6.1 configured -- resuming normal operations
When I run otool -L mod_wsgi.so is see:
mod_wsgi.so:
/System/Library/Frameworks/Python.framework/Versions/2.6/Python (compatibility version 2.6.0, current version 2.6.1)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)
What gives? Why is it linking with the system framework?
Here is the output from my mod_wsgi configure and build commands:
Archimedes:mod_wsgi-3.1 awolf$ ./configure --with-python=/usr/local/Cellar/python/2.6.4/bin/python
checking for apxs2... no
checking for apxs... /opt/apache2/bin/apxs
checking Apache version... 2.2.14
configure: creating ./config.status
config.status: creating Makefile
Archimedes:mod_wsgi-3.1 awolf$ make
/opt/apache2/bin/apxs -c -I/usr/local/Cellar/python/2.6.4/include/python2.6 -DNDEBUG -Wc,'-arch x86_64' mod_wsgi.c -L/usr/local/Cellar/python/2.6.4/lib -L/usr/local/Cellar/python/2.6.4/lib/python2.6/config -arch x86_64 -lpython2.6 -ldl
/Library/Webserver/build/libtool --silent --mode=compile gcc -prefer-pic -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -O2 -I/opt/apache2/include -I/opt/apache2/include -I/opt/apache2/include -arch x86_64 -I/usr/local/Cellar/python/2.6.4/include/python2.6 -DNDEBUG -c -o mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo
In file included from /usr/local/Cellar/python/2.6.4/include/python2.6/Python.h:125,
from mod_wsgi.c:135:
/usr/local/Cellar/python/2.6.4/include/python2.6/modsupport.h:27: warning: 'PyArg_ParseTuple' is an unrecognized format function type
/Library/Webserver/build/libtool --silent --mode=link gcc -o mod_wsgi.la -rpath /opt/apache2/modules -module -avoid-version mod_wsgi.lo -L/usr/local/Cellar/python/2.6.4/lib -L/usr/local/Cellar/python/2.6.4/lib/python2.6/config -arch x86_64 -lpython2.6 -ldl
Archimedes:mod_wsgi-3.1 awolf$ sudo make install
Password:
/opt/apache2/bin/apxs -i -S LIBEXECDIR=/opt/apache2/modules -n 'mod_wsgi' mod_wsgi.la
/Library/Webserver/build/instdso.sh SH_LIBTOOL='/Library/Webserver/build/libtool' mod_wsgi.la /opt/apache2/modules
/Library/Webserver/build/libtool --mode=install cp mod_wsgi.la /opt/apache2/modules/
cp .libs/mod_wsgi.so /opt/apache2/modules/mod_wsgi.so
cp .libs/mod_wsgi.lai /opt/apache2/modules/mod_wsgi.la
cp .libs/mod_wsgi.a /opt/apache2/modules/mod_wsgi.a
chmod 644 /opt/apache2/modules/mod_wsgi.a
ranlib /opt/apache2/modules/mod_wsgi.a
This post is old, but still turns up in searches about mac + homebrew + python, so I thought I'd add some useful information. I was having the problem as the OP, just with a different module (uwsgi). I learned that you don't have to abandon homebrew. Homebrew can, in fact, install python as a framework; you just have to tell it to do so:
% brew uninstall python
Uninstalling /usr/local/Cellar/python/2.7.2...
% brew install python --universal --framework
... and all's well.
Because for some reason some Python framework installs from source code, usually MacPorts, have something wrong with the information embedded in the Python framework and the run time look up path of the executable isn't set correctly. As a result it ends up using the Python framework from /System/Library instead.
When you run 'configure' for mod_wsgi add the additional option '--disable-framework'. Eg:
./configure --with-python=/usr/local/Cellar/python/2.6.4/bin/python --disable-framework
This will change how Python library/framework is linked and may resolve the problem.
For more details see bug fixes (1) and (2) in:
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0206
Graham helped me solve this over on the mod_wsgi mailing list.
http://groups.google.com/group/modwsgi/browse_thread/thread/4046eaf290a49b1e/ae14888450de39f5#ae14888450de39f5
Here's a summary:
The problem was my installation of python was done via Homebrew. Homebrew’s python is not installed as a framework OR dylib install so it could not be used for embedding (such as in Apache/mod_wsgi).
Instead I installed python 2.6.4 from source:
./configure --prefix=/usr/local/python-2.6.4 --enable-framework=/usr/local/python-2.6.4/frameworks --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 --with-universal-archs=3-way
make
sudo make install
I was able to build a version of python 2.6.4 that I could then build
mod_wsgi with:
./configure --with-python=/usr/local/python-2.6.4/bin/python
make
sudo make install
To confirm:
otool -L /opt/apache2/modules/ mod_wsgi.so
/opt/apache2/modules/mod_wsgi.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.0.0)
/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/Python (compatibility version 2.6.0, current version 2.6.0)
shows that python is now using the 2.6.4 framework and not the system one. When I start apache, I no longer get the version mismatch warnings.
I re-installed django, psycopg2, and so on into my new python installation and everything is working like a charm.
Thanks again for your help!