2009/9/13 John Blaze <[email protected]>: > > I've had a chance to look @ it and I notice that MacPorts in built > with 2.0.0 expat while the Apple version is build with 2.0.1. I > compiled Python 2.7a for fun and it embeds 2.0.0... I guess that bug > maybe back?
The expat issue shouldn't affect Python 2.5 onwards. Another similar clash is between mod_cache family of modules in Apache and bundled sqlite. The sqlite package used a name which clashed with the Apache module initialisation function, or vice versa, can't remember now. Newer versions of sqlite avoided the issue, so may newer Python is bundling newer sqlite instead. Graham > On Sep 9, 11:10 pm, Graham Dumpleton <[email protected]> > wrote: >> 2009/9/10 John Blaze <[email protected]>: >> >> >> >> > I just want to confirm that: >> > LDFLAGS = -F/usr/ports/Library/Frameworks -arch x86_64 >> >> Which can't work as -F will be ignored. Has to be -Wl,-F. >> >> > LDLIBS = -framework Python -ldl >> >> > got Snow Leopard to point to the correct version of Python. I just >> > had to remove all the symlinks to the Apple supplied Python. >> >> Which symlinks did you remove? You have likely now broken your OS >> installation as potentially other tools dependent on Apple Python >> being where it is. >> >> Since you said it still doesn't work, we get back to the original >> potentials issues I listed which you gave no response on as to whether >> there might be a factor. Please go back to original suggestions and >> comment on both and provide evidence of configuration where >> appropriate so know that no a factor. >> >> I also say way I said before. Just use the Apple supplied Apache and >> Python. They work. It is only MacPorts which is a problem. >> >> Graham >> >> >> >> > On Sep 9, 7:58 am, Graham Dumpleton <[email protected]> >> > wrote: >> >> Crap, crap, crap. Stupid changing MacOS X and broken Python installations. >> >> >> Use: >> >> >> LDFLAGS = -Wl,-F/usr/ports/Library/Frameworks -framework Python -u >> >> _PyMac_Error -arch x86_64 -arch i386 -arch ppc7400 >> >> LDLIBS = -ldl >> >> >> Graham >> >> >> 2009/9/9 Graham Dumpleton <[email protected]>: >> >> >> > Hmmm, probably forgetting that you are likely trying to use mod_wsgi >> >> > 2.5 and not 3.0 release candidate. Don't think you have actually said >> >> > what version you are using. >> >> >> > Can you get down: >> >> >> > http://code.google.com/p/modwsgi/source/browse/branches/mod_wsgi-2.X/... >> >> >> > and replace configure script with that and try again. It has a couple >> >> > of MacPorts fixes in it. Details in: >> >> >> > http://code.google.com/p/modwsgi/wiki/ChangesInVersion0206 >> >> >> > Since all the MacPorts people are trying to rebuild on Snow Leopard, >> >> > likely just hitting known issue which is fixed in that file but not >> >> > released. Usually MacPorts people are few and far between, but getting >> >> > a lot right now because of Snow Leopard. >> >> >> > When you have that newer configure file, then can start over and try >> >> > debugging again. >> >> >> > Graham >> >> >> > 2009/9/9 Graham Dumpleton <[email protected]>: >> >> >> Of all the combinations you have tried, have you yet tried: >> >> >> >> LDFLAGS = -F/usr/ports/Library/Frameworks -arch x86_64 -arch i386 >> >> >> -arch ppc7400 >> >> >> LDLIBS = -framework Python -ldl >> >> >> >> This is the final fallback. >> >> >> >> When you tried -F/-framework last time, you had wrong path for -F so >> >> >> not sure if you went back and tried above. >> >> >> >> Ensure you do a complete 'stop' and then 'start' of Apache and not a >> >> >> 'restart'. I presume you are using 'apachectl'. >> >> >> >> If that still doesn't work, then don't use MacPorts Apache and instead >> >> >> try using Apple supplied Apache. >> >> >> >> Preferably use both Apple supplied Apache and Python as the MacPorts >> >> >> ones are still giving some grief on Snow Leopard. >> >> >> >> Graham >> >> >> >> 2009/9/9 John Blaze <[email protected]>: >> >> >> >>> same thing >> >> >> >>> On Sep 8, 11:08 pm, John Blaze <[email protected]> wrote: >> >> >>>> just do be sure: >> >> >>>> LDFLAGS = -F/usr/ports/Library/Frameworks -L/usr/ports/Library/ >> >> >>>> Frameworks/Python.framework/Versions/2.6/lib/python2.6/config -arch >> >> >>>> x86_64 >> >> >> >>>> On Sep 8, 11:03 pm, Graham Dumpleton <[email protected]> >> >> >>>> wrote: >> >> >> >>>> > 2009/9/9 John Blaze <[email protected]>: >> >> >> >>>> > > I will note that this now happens -> >> >> >>>> > > [Tue Sep 08 22:46:54 2009] [warn] mod_wsgi: Compiled for >> >> >>>> > > Python/2.6.2. >> >> >>>> > > [Tue Sep 08 22:46:54 2009] [warn] mod_wsgi: Runtime using Python/ >> >> >>>> > > 2.6.1. >> >> >> >>>> > > I even changed the Makefile >> >> >> >>>> > > LDFLAGS = >> >> >>>> > > -F/usr/ports/Library/Frameworks/Python.framework/Versions/ >> >> >>>> > > 2.6/lib/python2.6/config -arch x86_64 >> >> >> >>>> > Wrong argument to -F, should be /usr/ports/Library/Frameworks as >> >> >>>> > per >> >> >>>> > my other email. >> >> >> >>>> > Please try what I said in other email first as I need that for >> >> >>>> > confirmation of whether I can use -F/-L/-l as a workaround for all >> >> >>>> > cases. >> >> >> >>>> > Graham >> >> >> >>>> > > LDLIBS = -framework Python -ldl >> >> >> >>>> > > make output: >> >> >> >>>> > > /usr/local/apache2/bin/apxs -c -I/usr/ports/Library/Frameworks/ >> >> >>>> > > Python.framework/Versions/2.6/include/python2.6 -DNDEBUG >> >> >>>> > > -Wc,'-arch >> >> >>>> > > x86_64' mod_wsgi.c >> >> >>>> > > -F/usr/ports/Library/Frameworks/Python.framework/ >> >> >>>> > > Versions/2.6/lib/python2.6/config -arch x86_64 -framework >> >> >>>> > > Python -ldl >> >> >>>> > > /usr/local/apache2/build/libtool --silent --mode=compile gcc >> >> >>>> > > -prefer- >> >> >>>> > > pic -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g >> >> >>>> > > -O2 - >> >> >>>> > > I/usr/ports/include -I/usr/local/apache2/include >> >> >>>> > > -I/usr/local/apache2/ >> >> >>>> > > include -I/usr/local/apache2/include -arch x86_64 >> >> >>>> > > -I/usr/ports/ >> >> >>>> > > Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 >> >> >>>> > > - >> >> >>>> > > DNDEBUG -c -o mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo >> >> >>>> > > mod_wsgi.c: In function ‘Adapter_output’: >> >> >>>> > > mod_wsgi.c:2868: warning: format ‘%d’ expects type ‘int’, but >> >> >>>> > > argument >> >> >>>> > > 3 has type ‘Py_ssize_t’ >> >> >>>> > > /usr/local/apache2/build/libtool --silent --mode=link gcc -o >> >> >>>> > > mod_wsgi.la -rpath /usr/local/apache2/modules -module -avoid- >> >> >>>> > > version mod_wsgi.lo -F/usr/ports/Library/Frameworks/ >> >> >>>> > > Python.framework/Versions/2.6/lib/python2.6/config -arch x86_64 - >> >> >>>> > > framework Python -ldl >> >> >> >>>> > > - but the same result for otool?? >> >> >> >>>> > > On Sep 8, 10:32 pm, John Blaze <[email protected]> wrote: >> >> >>>> > >> I'm using Snow Leopard and the above script works fine in >> >> >>>> > >> FreeBSD >> >> >>>> > >> (production) - this Snow Leopard is driving me nuts. >> >> >> >>>> > >> this is my ls -las >> >> >>>> > >> 0 drwxr-xr-x 12 root wheel 408 29 Aug 03:38 . >> >> >>>> > >> 0 drwxr-xr-x 631 root wheel 21454 29 Aug 11:11 .. >> >> >>>> > >> 32 -rw-r--r-- 1 root wheel 44405 8 Jul 02:57 Makefile >> >> >>>> > >> 16 -rw-r--r-- 1 root wheel 18265 8 Jul 02:56 Setup >> >> >>>> > >> 0 -rw-r--r-- 1 root wheel 368 8 Jul 02:56 Setup.config >> >> >>>> > >> 0 -rw-r--r-- 1 root wheel 41 8 Jul 02:56 Setup.local >> >> >>>> > >> 0 -rw-r--r-- 1 root wheel 2077 8 Jul 02:56 config.c >> >> >>>> > >> 0 -rw-r--r-- 1 root wheel 1457 8 Jul 02:56 config.c.in >> >> >>>> > >> 0 -rwxr-xr-x 1 root wheel 7122 8 Jul 02:56 install-sh >> >> >>>> > >> 8 lrwxr-xr-x 1 root wheel 15 29 Aug 03:38 >> >> >>>> > >> libpython2.6.a -> ../../../Python >> >> >> >>>> > >> 0 -rwxr-xr-x 1 root wheel 7431 8 Jul 02:56 makesetup >> >> >>>> > >> 16 -rw-r--r-- 1 root wheel 20640 8 Jul 02:56 python.o >> >> >> >>>> > >> my otool is >> >> >>>> > >> /usr/ports/apache2/modules/mod_wsgi.so: >> >> >>>> > >> >> >> >>>> > >> /usr/ports/Library/Frameworks/Python.framework/Versions/2.6/Python >> >> >>>> > >> (compatibility version 2.6.0, current version 2.6.0) >> >> >>>> > >> /usr/lib/libSystem.B.dylib (compatibility version >> >> >>>> > >> 1.0.0, current >> >> >>>> > >> version 123.0.0) >> >> >> >>>> > >> and only error Apache gives is: >> >> >>>> > >> [Tue Sep 08 22:26:13 2009] [error] [client 127.0.0.1] Premature >> >> >>>> > >> end of >> >> >>>> > >> script headers: wsgi_trac_handler.wsgi >> >> >> >>>> > >> On Sep 8, 7:11 pm, Graham Dumpleton <[email protected]> >> >> >>>> > >> wrote: >> >> >> >>>> > >> > 2009/9/9 John Blaze <[email protected]>: >> >> >> >>>> > >> > > Hi most of my install problems have been solved, but I keep >> >> >>>> > >> > > getting >> >> >>>> > >> > > this message on all me wsgi files: child pid 98608 exit >> >> >>>> > >> > > signal Trace/ >> >> >>>> > >> > > BPT trap (5) >> >> >> >>>> > >> > > This works fine >> >> >>>> > >> > > import sys, os >> >> >>>> > >> > > def application(environ, start_response): >> >> >>>> > >> > > status = '200 OK' >> >> >>>> > >> > > output = 'Hello World!' >> >> >>>> > >> > > print >> environ['wsgi.errors'], "application debug #1" >> >> >>>> > >> > > response_headers = [('Content-type', 'text/plain'), >> >> >>>> > >> > > ('Content-Length', str(len(output)))] >> >> >>>> > >> > > start_response(status, response_headers) >> >> >>>> > >> > > print >> environ['wsgi.errors'], "application debug #2" >> >> >>>> > >> > > return [output] >> >> >> >>>> > >> > > But I simple Trac wsgi file does not >> >> >> >>>> > >> > > import sys >> >> >>>> > >> > > sys.stdout = sys.stderr >> >> >> >>>> > >> > > import os >> >> >>>> > >> > > os.environ['TRAC_ENV'] = '/Users/jstates/Sites/Trac/theirry' >> >> >>>> > >> > > os.environ['PYTHON_EGG_CACHE'] = >> >> >>>> > >> > > '/Users/jstates/Sites/Trac/theirry/ >> >> >>>> > >> > > eggs' >> >> >>>> > >> > > import trac.web.main >> >> >>>> > >> > > application = trac.web.main.dispatch_request >> >> >> >>>> > >> > > Does that wsgi startup look correct, or what am I doing >> >> >>>> > >> > > wrong? >> >> >> >>>> > >> > Trac problems can come from a few areas. >> >> >> >>>> > >> > 1. Not setting: >> >> >> >>>> > >> > WSGIApplicationGroup %{GLOBAL} >> >> >> >>>> > >> > This is needed as Python wrappers for subversion only work >> >> >>>> > >> > reliably in >> >> >>>> > >> > main interpreter. >> >> >> >>>> > >> > 2. Mismatch in expat library used by Apache and by Python. If >> >> >>>> > >> > using >> >> >>>> > >> > Python 2.5 or later, shouldn't be a problem. >> >> >> >>>> > >> > 3. You are load subversion Apache modules, mod_dav_svn etc, >> >> >>>> > >> > and the >> >> >>>> > >> > version of subversion they use is different to that which >> >> >>>> > >> > Python >> >> >>>> > >> > subversion wrappers are using. >> >> >> >>>> > >> > 4. Mismatch in database library being used. Often caused by >> >> >>>> > >> > mod_php >> >> >>>> > >> > using a conflicting version. >> >> ... >> >> read more » > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
