mod_wsgi on Snow Leopard python version mismatch
Adam Wolf
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)
It linking with the system framework- not the one I installed in /usr/
local using Homebrew.
Upon Graham's advice at StackOverflow (http://stackoverflow.com/
questions/1942462/modwsgi-on-snow-leopard-python-version-mismatch) I
tried cleaning my build and then running the configure script with --
disable-framework
./configure --with-python=/usr/local/Cellar/python/2.6.4/bin/python --
disable-framework
This gave me the same results.
Here is the output of one such build attempt:
Archimedes:~ awolf$ sudo rm /opt/apache2/modules/mod_wsgi.so
Password:
Archimedes:~ awolf$ cd ~/Downloads/mod_wsgi-3.1
Archimedes:mod_wsgi-3.1 awolf$ rm -rf build
Archimedes:mod_wsgi-3.1 awolf$ make distclean
rm -rf .libs
rm -f mod_wsgi.o mod_wsgi.la mod_wsgi.lo mod_wsgi.slo mod_wsgi.loT
rm -f config.log config.status
rm -rf autom4te.cache
rm -f Makefile Makefile.in
Archimedes:mod_wsgi-3.1 awolf$ ./configure --with-python=/usr/local/
Cellar/python/2.6.4/bin/python --disable-framework
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
/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
----------------------------------------------------------------------
Libraries have been installed in:
/opt/apache2/modules
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable
during execution
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 /opt/apache2/modules/mod_wsgi.so
Archimedes:mod_wsgi-3.1 awolf$ sudo apachectl -k stop
Archimedes:mod_wsgi-3.1 awolf$ sudo apachectl -k start
Thanks,
Adam
Graham Dumpleton
That this is using:
-L/usr/local/Cellar/python/2.6.4/lib
-L/usr/local/Cellar/python/2.6.4/lib/python2.6/config -lpython2.6
indicates --enable-framework did what it was mean't to. Ie., switch
from using -F/-framework to -L/-l.
Can you look in:
-L/usr/local/Cellar/python/2.6.4/lib/python2.6/config/Makefile
and post the value of the CONFIG_ARGS variable.
Is this Python installation one you installed from source, or is it a
binary package from somewhere else such as MacPorts? MacPorts give so
much grief.
While you at it, what do you get for:
ls -las /usr/local/Cellar/python/2.6.4/lib
ls -las /usr/local/Cellar/python/2.6.4/lib/python2.6/config
file /usr/local/Cellar/python/2.6.4/lib/python2.6/config/libpython*
Graham
> --
>
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>
>
Adam Wolf
CONFIG_ARGS= '--prefix=/usr/local/Cellar/python/2.6.4' 'CC=/
Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2' 'CFLAGS=-O4 -march=core2 -
mmmx -msse4.1 -w -pipe' 'LDFLAGS=-L/usr/local/Cellar/readline/6.0/lib'
'CPPFLAGS=-I/usr/local/Cellar/readline/6.0/include'
This is a python installation made by the new mac package management
script Homebrew. I'm following this advice:
http://benkreeger.com/personal/conquering-symbol-not-found-_pqbackendpid
to solve the problem described there. The alternative is to force
everything, including mod_wsgi, to run in 32-bit mode which is not
preferable to me.
Archimedes:config awolf$ ls -las /usr/local/Cellar/python/2.6.4/lib
total 8376
0 drwxr-xr-x 4 root wheel 136 Dec 19 18:33 .
0 drwxr-xr-x 8 root wheel 272 Dec 19 18:33 ..
8376 -r--r--r-- 2 root wheel 4285288 Dec 19 18:33 libpython2.6.a
0 drwxr-xr-x 631 root wheel 21454 Dec 19 18:33 python2.6
Archimedes:config awolf$ ls -las /usr/local/Cellar/python/2.6.4/lib/
python2.6/config
total 8576
0 drwxr-xr-x 12 root wheel 408 Dec 19 18:33 .
0 drwxr-xr-x 631 root wheel 21454 Dec 19 18:33 ..
88 -rw-r--r-- 1 root wheel 42950 Dec 19 18:33 Makefile
40 -rw-r--r-- 1 root wheel 18265 Dec 19 18:33 Setup
8 -rw-r--r-- 1 root wheel 368 Dec 19 18:33 Setup.config
8 -rw-r--r-- 1 root wheel 41 Dec 19 18:33 Setup.local
8 -rw-r--r-- 1 root wheel 2077 Dec 19 18:33 config.c
8 -rw-r--r-- 1 root wheel 1457 Dec 19 18:33 config.c.in
16 -rwxr-xr-x 1 root wheel 7122 Dec 19 18:33 install-sh
8376 -r--r--r-- 2 root wheel 4285288 Dec 19 18:33 libpython2.6.a
16 -rwxr-xr-x 1 root wheel 7431 Dec 19 18:33 makesetup
8 -rw-r--r-- 1 root wheel 2060 Dec 19 18:33 python.o
Archimedes:config awolf$ file /usr/local/Cellar/python/2.6.4/lib/
python2.6/config/libpython*
/usr/local/Cellar/python/2.6.4/lib/python2.6/config/libpython2.6.a:
current ar archive random library
Thanks,
-Adam
On Dec 22, 7:54 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> 2009/12/23 Adam Wolf <adamaw...@gmail.com>:
Graham Dumpleton
> Graham-
>
> CONFIG_ARGS= '--prefix=/usr/local/Cellar/python/2.6.4' 'CC=/
> Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2' 'CFLAGS=-O4 -march=core2 -
> mmmx -msse4.1 -w -pipe' 'LDFLAGS=-L/usr/local/Cellar/readline/6.0/lib'
> 'CPPFLAGS=-I/usr/local/Cellar/readline/6.0/include'
>
> This is a python installation made by the new mac package management
> script Homebrew. I'm following this advice:
Which is not installed as a framework install, nor even as a dylib
install. This possibly makes it unusable for embedding such as with
Apache/mod_wsgi as it only provides a static library and under MacOS X
it may not be possible to link them into dynamically loadable objects.
Is there a specific reason why you cannot just use Python 2.6.1 as
supplied by Apple? What changes are there in 2.6.2-2.6.4 that you
cannot do without?
Graham
Adam Wolf
The version of Python 2.6.1 as supplied by Apple is incompatible with
the postgres DB adapter psycopg2. A workaround is running:
defaults write com.apple.versioner.python Prefer-32-Bit -bool yes
to force python to run in 32 bit mode.
This solved the problem while using the python development server.
However, when I went to set up a production environment using
mod_wsgi, psycopg2 started to throw the same error as before:
Symbol not found: _PQbackendPID
I imagine that mod_wsgi running in 64-bit mode is forcing python back
into 64-bit mode also, which causes psycopg2 to fail. Perhaps I could
force mod_wsgi to run in 32-bit mode also... but that kinda sucks.
Then I found this:
http://benkreeger.com/personal/conquering-symbol-not-found-_pqbackendpid
which advised using Homebrew to install python and postgresql to
resolve the issue. This did resolve the issue on the django
development server in 64-bit mode. However, upon review of this advice
I don't see why it is necessary to use the Homebrew python
installation.
I'll give it a shot with Apple's 2.6.1 now...
On Dec 23, 3:11 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> 2009/12/24 Adam Wolf <adamaw...@gmail.com>:
Graham Dumpleton
You will need to have XCode installed.
Use 'configure' arguments to Python as documented in:
./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=all
This will install stuff under /usr/local/python-2.6.4 and
/Applications/Python 2.6.
When you build mod_wsgi then use:
./configure --with-python=/usr/local/python-2.6.4/bin/python
You obviously will need to install Python wrappers for PostgreSQL and
other Python packages with that /usr/local/python2.6 installation.
Graham
2009/12/24 Adam Wolf <adam...@gmail.com>:
Adam Wolf
postgresql was not compatible with psycopg2).
I'm using 10.6 so shouldn't it be:
--enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6
?
Thanks
On Dec 23, 4:11 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> Can you install Python 2.6.4 from source code yourself.
>
> You will need to have XCode installed.
>
> Use 'configure' arguments to Python as documented in:
>
> ./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=all
>
> This will install stuff under /usr/local/python-2.6.4 and
> /Applications/Python 2.6.
>
> When you build mod_wsgi then use:
>
> ./configure --with-python=/usr/local/python-2.6.4/bin/python
>
> You obviously will need to install Python wrappers for PostgreSQL and
> other Python packages with that /usr/local/python2.6 installation.
>
> Graham
>
> 2009/12/24 Adam Wolf <adamaw...@gmail.com>:
> ...
>
> read more »
Graham Dumpleton
> Ok, I'll give that a shot now (Apple's 2.6.1 with Homebrew's
> postgresql was not compatible with psycopg2).
>
> I'm using 10.6 so shouldn't it be:
>
> --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6
Not necessarily. That says what the oldest version of MacOS X is that
you want to support with that installation. So, no harm in leaving it
as 10.5 and not sure you would get any benefit in saying to target
10.6.
Graham
Adam Wolf
installed form source.
First, --with-universal-archs=all doesn't work on Snow Leopard:
http://bugs.python.org/issue6245
Roland mentions only adding the "intel" and "3-way" options for 2.7
and 3.1 but it seems to be available in my 2.6.4 configure script. So
running it with
--with-universal-archs=intel
gets past the wchar_t size error, but now I get:
...
configure: creating ./config.status
config.status: error: cannot find input file: Mac/Makefile.in
...
In fact, just ./configure gives me the same error.
My /Mac directory is completely empty so I'm thinking its a bug in
python's configure script. I seem to be the only person in the world
who has had this problem.
Could using the Mac Installer Disc Image work? Otherwise I'll open a
bug with the python guys if you don't have any other ideas.
Thanks
Adam
On Dec 23, 4:47 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> ...
>
> read more »
Graham Dumpleton
built 2.6.2 on Snow Leopard, I used:
./configure --prefix=/usr/local/python-2.6.2
--enable-framework=/usr/local/python-2.6.2/frameworks
--enable-universalsdk=/ --with-universal-archs=all
I'll get down 2.6.4 and see what happens when I try and built it.
Graham
2009/12/24 Adam Wolf <adam...@gmail.com>:
Adam Wolf
checking size of wchar_t... configure: error: cannot compute sizeof
(wchar_t)
changing back to --with-universal-archs=intel I still get the:
config.status: error: cannot find input file: Mac/Makefile.in
Does --with-universal-archs=all work on your SL installation?
On Dec 23, 6:44 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> Try dropping the MACOSX_DEPLOYMENT_TARGET option completely. When I
> built 2.6.2 on Snow Leopard, I used:
>
> ./configure --prefix=/usr/local/python-2.6.2
> --enable-framework=/usr/local/python-2.6.2/frameworks
> --enable-universalsdk=/ --with-universal-archs=all
>
> I'll get down 2.6.4 and see what happens when I try and built it.
>
> Graham
>
> 2009/12/24 Adam Wolf <adamaw...@gmail.com>:
> ...
>
> read more »
Graham Dumpleton
1. Trash the whole unpacked Python source directory and start from new
tar ball extract. That or run 'make distclean'.
2. Make sure using /usr/bin/gcc.
grumpy:Python-2.6.2 grahamd$ which cc
/usr/bin/cc
grumpy:Python-2.6.2 grahamd$ which gcc
/usr/bin/gcc
If not, take any MacPorts or Homebrew directories out of PATH which
have alternate gcc installation.
3. Run configure for Python as:
./configure --prefix=/usr/local/python-2.6.4
--enable-framework=/usr/local/python-2.6.4/frameworks
--enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5
That is, get rid of --with-universal-archs=all completely. You still
need MACOSX_DEPLOYMENT_TARGET=10.5.
4. Do the make and make install.
5. Build mod_wsgi using --with-python option and the --disable-framework option.
grumpy:mod_wsgi-4.X-2 grahamd$ ./configure
--with-python=/usr/local/python-2.6.4/bin/python --disable-framework
checking for apxs2... no
checking for apxs... /usr/sbin/apxs
checking Apache version... 2.2.13
configure: creating ./config.status
config.status: creating Makefile
grumpy:mod_wsgi-4.X-2 grahamd$ make
/usr/sbin/apxs -c
-I/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/include/python2.6
-DNDEBUG -Wc,'-arch x86_64' -Wc,'-arch i386' -Wc,'-arch ppc7400'
mod_wsgi.c -L/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/lib
-L/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/lib/python2.6/config
-arch x86_64 -arch i386 -arch ppc7400 -lpython2.6 -ldl
/usr/share/apr-1/build-1/libtool --silent --mode=compile gcc
-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/local/include
-I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1
-arch x86_64 -arch i386 -arch ppc7400
-I/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/include/python2.6
-DNDEBUG -c -o mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo
/usr/share/apr-1/build-1/libtool --silent --mode=link gcc -o
mod_wsgi.la -rpath /usr/libexec/apache2 -module -avoid-version
mod_wsgi.lo -L/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/lib
-L/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/lib/python2.6/config
-arch x86_64 -arch i386 -arch ppc7400 -lpython2.6 -ldl
warning: no debug symbols in executable (-arch x86_64)
warning: no debug symbols in executable (-arch i386)
warning: no debug symbols in executable (-arch ppc7400)
grumpy:mod_wsgi-4.X-2 grahamd$ make
make: Nothing to be done for `all'.
grumpy:mod_wsgi-4.X-2 grahamd$ sudo make install
/usr/sbin/apxs -i -S LIBEXECDIR=/usr/libexec/apache2 -n 'mod_wsgi' mod_wsgi.la
/usr/share/httpd/build/instdso.sh
SH_LIBTOOL='/usr/share/apr-1/build-1/libtool' mod_wsgi.la
/usr/libexec/apache2
/usr/share/apr-1/build-1/libtool --mode=install cp mod_wsgi.la
/usr/libexec/apache2/
cp .libs/mod_wsgi.so /usr/libexec/apache2/mod_wsgi.so
cp .libs/mod_wsgi.lai /usr/libexec/apache2/mod_wsgi.la
cp .libs/mod_wsgi.a /usr/libexec/apache2/mod_wsgi.a
chmod 644 /usr/libexec/apache2/mod_wsgi.a
ranlib /usr/libexec/apache2/mod_wsgi.a
----------------------------------------------------------------------
Libraries have been installed in:
/usr/libexec/apache2
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable
during execution
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 /usr/libexec/apache2/mod_wsgi.so
grumpy:mod_wsgi-4.X-2 grahamd$ sudo /usr/sbin/apachectl stop
grumpy:mod_wsgi-4.X-2 grahamd$ sudo /usr/sbin/apachectl -t
Warning: DocumentRoot [/usr/docs/dummy-host.example.com] does not exist
Warning: DocumentRoot [/usr/docs/dummy-host2.example.com] does not exist
Syntax OK
grumpy:mod_wsgi-4.X-2 grahamd$ sudo /usr/sbin/apachectl start
That works for me.
Graham
2009/12/24 Graham Dumpleton <graham.d...@gmail.com>:
Graham Dumpleton
I had to use --disable-framework because else you got:
grumpy:mod_wsgi-4.X-2 grahamd$ sudo /usr/sbin/apachectl -t
httpd: Syntax error on line 118 of /private/etc/apache2/httpd.conf:
Cannot load /usr/libexec/apache2/mod_wsgi.so into server:
dlopen(/usr/libexec/apache2/mod_wsgi.so, 10): Symbol not found:
_PyBool_Type\n Referenced from: /usr/libexec/apache2/mod_wsgi.so\n
Expected in: flat namespace\n in /usr/libexec/apache2/mod_wsgi.so
If you use --disable-framework, although it runs you have:
grumpy:mod_wsgi-4.X-2 grahamd$ otool -L .libs/mod_wsgi.so
.libs/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)
Right now have no idea what they have broken.
Graham Dumpleton
--with-universal-archs=all
when building Python else it doesn't build 64-bit, but Python
configure script is broken when specifying 'all' or '64-bit'.
Being Christmas, not sure when I will get too look at this. It does
mention this error in:
http://bugs.python.org/issue1099
but that seems to be for when debugging being enabled.
I'll have to revise what the so called voodoo is for build a framework
build on MacOS X is.
:-(
Graham Dumpleton
* ``3-way``: ``ppc``, ``i386`` and ``x86_64``
* ``intel``: ``i386``, ``x86_64``
To build a universal binary that includes a 64-bit architecture you must build
on a system running OSX 10.5 or later. The ``all`` flavour can only be build on
OSX 10.5.
So, can't use all, but only '3-way' or 'intel'.
I really got to run now and so can't wait for Python to finish
building, but is at least building when use:
./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
Can only see later if can then build mod_wsgi against that properly
and whether need --disable-framework option or not.
Adam Wolf
Thanks for all of your help with this. I'll keep hacking away at it
and let you know how it goes (though... I'm still stuck on ./configure
for python).
-Adam
On Dec 23, 7:36 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> Documentation says:
>
> * ``3-way``: ``ppc``, ``i386`` and ``x86_64``
>
> * ``intel``: ``i386``, ``x86_64``
>
> To build a universal binary that includes a 64-bit architecture you must build
> on a system running OSX 10.5 or later. The ``all`` flavour can only be build on
> OSX 10.5.
>
> So, can't use all, but only '3-way' or 'intel'.
>
> I really got to run now and so can't wait for Python to finish
> building, but is at least building when use:
>
> ./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
>
> Can only see later if can then build mod_wsgi against that properly
> and whether need --disable-framework option or not.
>
> Graham
>
> 2009/12/24 Graham Dumpleton <graham.dumple...@gmail.com>:
>
>
>
> > I am in a hurry so going to have to go soon. You really do need:
>
> > --with-universal-archs=all
>
> > when building Python else it doesn't build 64-bit, but Python
> > configure script is broken when specifying 'all' or '64-bit'.
>
> > Being Christmas, not sure when I will get too look at this. It does
> > mention this error in:
>
> >http://bugs.python.org/issue1099
>
> > but that seems to be for when debugging being enabled.
>
> > I'll have to revise what the so called voodoo is for build a framework
> > build on MacOS X is.
>
> > :-(
>
> > Graham
>
> > 2009/12/24 Graham Dumpleton <graham.dumple...@gmail.com>:
> >> Scratch that. Something is indeed amiss.
>
> >> I had to use --disable-framework because else you got:
>
> >> grumpy:mod_wsgi-4.X-2 grahamd$ sudo /usr/sbin/apachectl -t
> >> httpd: Syntax error on line 118 of /private/etc/apache2/httpd.conf:
> >> Cannot load /usr/libexec/apache2/mod_wsgi.so into server:
> >> dlopen(/usr/libexec/apache2/mod_wsgi.so, 10): Symbol not found:
> >> _PyBool_Type\n Referenced from: /usr/libexec/apache2/mod_wsgi.so\n
> >> Expected in: flat namespace\n in /usr/libexec/apache2/mod_wsgi.so
>
> >> If you use --disable-framework, although it runs you have:
>
> >> grumpy:mod_wsgi-4.X-2 grahamd$ otool -L .libs/mod_wsgi.so
> >> .libs/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)
>
> >> Right now have no idea what they have broken.
>
> >> Graham
>
> >> 2009/12/24 Graham Dumpleton <graham.dumple...@gmail.com>:
> >>> -I/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/include/ python2.6
> >>> 2009/12/24 Graham Dumpleton <graham.dumple...@gmail.com>:
> >>>> Try dropping the MACOSX_DEPLOYMENT_TARGET option completely. When I
> >>>> built 2.6.2 on Snow Leopard, I used:
>
> >>>> ./configure --prefix=/usr/local/python-2.6.2
> >>>> --enable-framework=/usr/local/python-2.6.2/frameworks
> >>>> --enable-universalsdk=/ --with-universal-archs=all
>
> >>>> I'll get down 2.6.4 and see what happens when I try and built it.
>
> >>>> Graham
>
> >>>> 2009/12/24 Adam Wolf <adamaw...@gmail.com>:
> ...
>
> read more »
Adam Wolf
Success.
Using you configure flags:
./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
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
Archimedes:mod_wsgi-3.1 awolf$ 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)
I re-installed django, psycopg2, etc and everything is working like a
charm.
Thanks again for your help!
On Dec 23, 7:36 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> Documentation says:
>
> * ``3-way``: ``ppc``, ``i386`` and ``x86_64``
>
> * ``intel``: ``i386``, ``x86_64``
>
> To build a universal binary that includes a 64-bit architecture you must build
> on a system running OSX 10.5 or later. The ``all`` flavour can only be build on
> OSX 10.5.
>
> So, can't use all, but only '3-way' or 'intel'.
>
> I really got to run now and so can't wait for Python to finish
> building, but is at least building when use:
>
> ./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
>
> Can only see later if can then build mod_wsgi against that properly
> and whether need --disable-framework option or not.
>
> Graham
>
> 2009/12/24 Graham Dumpleton <graham.dumple...@gmail.com>:
>
>
>
> > I am in a hurry so going to have to go soon. You really do need:
>
> > --with-universal-archs=all
>
> > when building Python else it doesn't build 64-bit, but Python
> > configure script is broken when specifying 'all' or '64-bit'.
>
> > Being Christmas, not sure when I will get too look at this. It does
> > mention this error in:
>
> >http://bugs.python.org/issue1099
>
> > but that seems to be for when debugging being enabled.
>
> > I'll have to revise what the so called voodoo is for build a framework
> > build on MacOS X is.
>
> > :-(
>
> > Graham
>
> > 2009/12/24 Graham Dumpleton <graham.dumple...@gmail.com>:
> >> Scratch that. Something is indeed amiss.
>
> >> I had to use --disable-framework because else you got:
>
> >> grumpy:mod_wsgi-4.X-2 grahamd$ sudo /usr/sbin/apachectl -t
> >> httpd: Syntax error on line 118 of /private/etc/apache2/httpd.conf:
> >> Cannot load /usr/libexec/apache2/mod_wsgi.so into server:
> >> dlopen(/usr/libexec/apache2/mod_wsgi.so, 10): Symbol not found:
> >> _PyBool_Type\n Referenced from: /usr/libexec/apache2/mod_wsgi.so\n
> >> Expected in: flat namespace\n in /usr/libexec/apache2/mod_wsgi.so
>
> >> If you use --disable-framework, although it runs you have:
>
> >> grumpy:mod_wsgi-4.X-2 grahamd$ otool -L .libs/mod_wsgi.so
> >> .libs/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)
>
> >> Right now have no idea what they have broken.
>
> >> Graham
>
> >> 2009/12/24 Graham Dumpleton <graham.dumple...@gmail.com>:
> >>> -I/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/include/ python2.6
> >>> 2009/12/24 Graham Dumpleton <graham.dumple...@gmail.com>:
> >>>> Try dropping the MACOSX_DEPLOYMENT_TARGET option completely. When I
> >>>> built 2.6.2 on Snow Leopard, I used:
>
> >>>> ./configure --prefix=/usr/local/python-2.6.2
> >>>> --enable-framework=/usr/local/python-2.6.2/frameworks
> >>>> --enable-universalsdk=/ --with-universal-archs=all
>
> >>>> I'll get down 2.6.4 and see what happens when I try and built it.
>
> >>>> Graham
>
> >>>> 2009/12/24 Adam Wolf <adamaw...@gmail.com>:
> ...
>
> read more »
vince
i need those library from macport instead of rebuild my own version of
python.
i am only able to build with the python come with snow leopard.
here's the error i got:
root ~/Downloads/mod_wsgi-3.1 # make clean
rm -rf .libs
rm -f mod_wsgi.o mod_wsgi.la mod_wsgi.lo mod_wsgi.slo mod_wsgi.loT
rm -f config.log config.status
rm -rf autom4te.cache
root ~/Downloads/mod_wsgi-3.1 # ./configure --with-python=/opt/local/
bin/python2.5
checking for apxs2... no
checking for apxs... /usr/sbin/apxs
checking Apache version... 2.2.13
configure: creating ./config.status
config.status: creating Makefile
root ~/Downloads/mod_wsgi-3.1 # make
/usr/sbin/apxs -c -I/opt/local/Library/Frameworks/Python.framework/
Versions/2.5/include/python2.5 -DNDEBUG -Wc,'-arch x86_64' -Wc,'-arch
i386' -Wc,'-arch ppc7400' mod_wsgi.c -Wl,-F/opt/local/Library/
Frameworks -framework Python -u _PyMac_Error /opt/local/Library/
Frameworks/ -arch x86_64 -arch i386 -arch ppc7400 -ldl
/usr/share/apr-1/build-1/libtool --silent --mode=compile gcc -
DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/local/include -I/usr/
include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -arch
x86_64 -arch i386 -arch ppc7400 -I/opt/local/Library/Frameworks/
Python.framework/Versions/2.5/include/python2.5 -DNDEBUG -c -o
mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo
In file included from /opt/local/Library/Frameworks/Python.framework/
Versions/2.5/include/python2.5/Python.h:57,
from mod_wsgi.c:135:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/include/
python2.5/pyport.h:761:2: error: #error "LONG_BIT definition appears
wrong for platform (bad gcc/glibc config?)."
In file included from /opt/local/Library/Frameworks/Python.framework/
Versions/2.5/include/python2.5/Python.h:57,
from mod_wsgi.c:135:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/include/
python2.5/pyport.h:761:2: error: #error "LONG_BIT definition appears
wrong for platform (bad gcc/glibc config?)."
lipo: can't figure out the architecture type of: /var/tmp//
ccKY9Jvo.out
apxs:Error: Command failed with rc=65536
.
make: *** [mod_wsgi.la] Error 1
root ~/Downloads/mod_wsgi-3.1 # make clean
rm -rf .libs
rm -f mod_wsgi.o mod_wsgi.la mod_wsgi.lo mod_wsgi.slo mod_wsgi.loT
rm -f config.log config.status
rm -rf autom4te.cache
root ~/Downloads/mod_wsgi-3.1 # ./configure --with-python=/opt/local/
bin/python2.5 --disable-framework
checking for apxs2... no
checking for apxs... /usr/sbin/apxs
checking Apache version... 2.2.13
configure: creating ./config.status
config.status: creating Makefile
root ~/Downloads/mod_wsgi-3.1 # make
/usr/sbin/apxs -c -I/opt/local/Library/Frameworks/Python.framework/
Versions/2.5/include/python2.5 -DNDEBUG -Wc,'-arch x86_64' -Wc,'-arch
i386' -Wc,'-arch ppc7400' mod_wsgi.c -L/opt/local/Library/Frameworks/
Python.framework/Versions/2.5/lib -L/opt/local/Library/Frameworks/
Python.framework/Versions/2.5/lib/python2.5/config -arch x86_64 -arch
i386 -arch ppc7400 -lpython2.5 -ldl
/usr/share/apr-1/build-1/libtool --silent --mode=compile gcc -
DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/local/include -I/usr/
include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -arch
x86_64 -arch i386 -arch ppc7400 -I/opt/local/Library/Frameworks/
Python.framework/Versions/2.5/include/python2.5 -DNDEBUG -c -o
mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo
In file included from /opt/local/Library/Frameworks/Python.framework/
Versions/2.5/include/python2.5/Python.h:57,
from mod_wsgi.c:135:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/include/
python2.5/pyport.h:761:2: error: #error "LONG_BIT definition appears
wrong for platform (bad gcc/glibc config?)."
In file included from /opt/local/Library/Frameworks/Python.framework/
Versions/2.5/include/python2.5/Python.h:57,
from mod_wsgi.c:135:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/include/
python2.5/pyport.h:761:2: error: #error "LONG_BIT definition appears
wrong for platform (bad gcc/glibc config?)."
lipo: can't figure out the architecture type of: /var/tmp//
ccDMjNIY.out
apxs:Error: Command failed with rc=65536
.
make: *** [mod_wsgi.la] Error 1