2009/5/21 Graham Dumpleton <[email protected]>: > 2009/5/21 chris <[email protected]>: >> >> Thanks a lot for your help, Graham! >> >> On May 21, 2:48 pm, Graham Dumpleton <[email protected]> >> wrote: >>> >>> Try modifying the makefile again, but this time use: >>> >>> LDFLAGS = -Wl,-F/usr/local/python-2.5.4/frameworks -framework Python -arch >>> i386 >>> LDLIBS = -ldl >> >> This seemed to do the trick! > > I have to do some more testing on my system then. :-( > >>> If using -F, you need the '-framework Python' as well. Also should be >>> '-Wl,-F' and not '-Wl -F'. Finally, drop the -lpython2.5 from LDLIBS. >>> I am guess here that -ldl is left. Just remove -lpython2.5 and leave >>> whatever else was there. >>> >>> This is getting stupid. If I use -Wl,-F/-framework it breaks MacPorts >>> most of the time. If I use -L/-l which appears to be the preferred >>> Python way when the libpythonX.Y.a symlink to Python framework exists, >>> it is sometimes breaking where Python major/minor version is 2.5. >>> >> >> Is it necessary to use a Framework? I would rather not, but something >> on the Wiki made me believe that it is required for self-compiled >> pythons. > > I have never tried doing it without a framework and likely that > mod_wsgi wouldn't link. It only even uses -L/-l approach if the > libpythonX.Y.a symlink to framework exists. If you don't use a > framework install, there is likely to be a libpythonX.Y.dylib > somewhere and since don't specifically check for that, would on MacOS > X fallback to looking for framework with -F/-framework. > >>> There is also still a problem where you get: >>> >>> /usr/local/python-2.5.4/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?)." >>> >>> If truly installed as all architectures and using MacOS X gcc, you >>> shouldn't get that. >> >> Maybe. In fact I am most interested in getting the 32 bit version >> running, since it seems some of the C-Extensions (PIL?) will not run >> otherwise. > > It wouldn't have matter if all architectures are in mod_wsgi.so, > presuming you could get it to build like that. As I said, seems to be > something a bit odd about your Python installation as that LONG_BIT > error usually indicates that it wasn't installed with all > architectures. > >> But now I finally got mod_wsgi running with the right version, so next >> is getting my django application going! > > If using Apache from Apple, you may now need to deal with issue of > making it run as 32 bit instead of 64 bit.
Only Python 2.6 supports the '--with-universal-archs=all' configure option. If using Python 2.5 will only be possible to build for 32 bit. That explains a lot. I'd say it is the case that for Python 2.5 and older you must use -F/-framework as well. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
