I'm trying to reproduce some problem with "python's restricted mode" which I'm getting on x86 branch in mod_python application. I found some other reports and some testcase. On my test computer being in ~x86 I cannot even execute it and I believe the python-2.4 integration or mod_python itself is wrong: $ python test.py Traceback (most recent call last): File "test.py", line 3, in ? from mod_python import apache, util File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 28, in ? import _apache ImportError: No module named _apache $ I'm using dev-python/mod_python-3.1.4, dev-python/mysql-python-1.2.0, net-www/apache-2.0.54-r11. $ emerge info Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.13-rc1 i686) ================================================================= System uname: 2.6.13-rc1 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.12 dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.8 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18 virtual/os-headers: 2.4.19-r1, 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -mmmx -msse -msse2 -msse3 -fomit-frame-pointer -march=pentium4 -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/ env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /v ar/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/afs/etc /etc/gconf /etc/terminfo /etc/texmf/web2c /usr/vice/etc/cacheinfo /etc/env.d" CXXFLAGS="-O3 -mmmx -msse -msse2 -msse3 -fomit-frame-pointer -march=pentium4 -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.muni.cz/pub/linux/gentoo http://gentoo.mirror.icd.hu/ http://ftp-stud.fht-esslingen.de/pub/Mirror s/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/" LINGUAS="cs cz en" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X Xaw3d aalib acpi adns afs alsa apache2 apm arts ati avcodec avi bidi bitmap-fonts bonobo caca cdparanoia crypt c scope cups curl dba dga directfb distcc divx divx4 divx4linux divx5 divx5linux dv dvb dvd dvdr dvdread emacs emacs-w3 embos s encode esd ethereal evo f77 faac faad faad2 fam fame fbcon ffmpeg flac flash foomaticdb fortran fvwm fvwm2 gb gd gdbm ggi gif gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile i8x0 icc imagemagick imlib imlib2 innodb java jpeg junit lcms leim libg++ libwww live lpthread lzo lzw-tiff mad mcal mesa mikmod mmx mmx2 motif mozilla mp3 mpeg mule mysql ncurses network nls nptl ogg oggvorbis opengl oss pam pda pdflib perl php php4 plotutils png ppds pthread pthreads python qt qtx quicktime readline rtc samba scanner sdl slang slp speex spell sse sse2 sse3 ssl svga tcltk tcpd tetex tex theora thread threads tiff truetyp e truetype-fonts type1-fonts unicode usb v4l v4l2 vorbis win32 winvidix wmf xine xml xml2 xmms xosd xv xvid xvmc yv12 zeo z lib video_cards_radeon linguas_cs linguas_cz linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS
Created attachment 62420 [details] testcase testcase from original bugreport at http://www.modpython.org/pipermail/mod_python/2005-January/017129.html
http://www.modpython.org/pipermail/mod_python/2004-November/016726.html http://www.modpython.org/pipermail/mod_python/2004-November/016821.html http://www.modpython.org/pipermail/mod_python/2004-November/016822.html From this I gather this might be a misconfiguration on my side ... Strange, my python programs work when placed in the very same directory. I don't have any ExecCGIs set anywhere. :( I believe I hit some other problem. Why isn't 3.1.4 marked stable on x86? :(
After several hours spent with Google I think I face some of the _many_ problems with modules imports. I doubt I'll manage to figure out what's my case. :( The good news here is that mod_python-3.2.0 might soon reach the us. The discussions are just about which bugfixes have to be done yet. I've tested the cvs HEAD but it's missing at the moment at least a patch said to be fixed in "3.2.0" - I guess there's a branch which has the patch. If someone cares, I found the path to flex is hardcoded to /usr/local/bin/flex in some src/Makefile.in if I remember right. Before the update happens flex must be upgraded and stable to 2.5.31 (they use "flex -R "). Even my ~x86 host runs only at 2.5.4a-r6. :(
Hi, although I very much appreciate someone picked up the current cvs, There is the problem that flex dependecy must be raised >=2.5.31. And, the patch for the full path to /usr/local/bin/flex should be in cvs, so maybe another branch should be checked out! /usr/share/apr-0/build/libtool --silent --mode=compile i686-pc-linux-gnu-gcc -prefer-pic -O3 -mmmx -msse -msse2 -msse3 -fomit-frame-pointer -march=pentium4 -funroll-loops -pipe -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pthread -I/usr/include/apache2 -I/usr/include/apr-0 -I/usr/include/apr-0 -I/var/tmp/portage/mod_python-20050701/work/mod_python-20050701/src/include -I/usr/include/apache2 -I/usr/include/python2.4 -c -o hlistobject.lo hlistobject.c && touch hlistobject.slo In file included from /usr/include/python2.4/Python.h:8, from /var/tmp/portage/mod_python-20050701/work/mod_python-20050701/src/include/mod_python.h:57, from hlistobject.c:28: /usr/include/python2.4/pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/sys/types.h:27, from /usr/include/apr-0/apr.h:112, from /usr/include/apache2/ap_config.h:20, from /usr/include/apache2/httpd.h:30, from /var/tmp/portage/mod_python-20050701/work/mod_python-20050701/src/include/mod_python.h:32, from hlistobject.c:28: /usr/include/features.h:150:1: warning: this is the location of the previous definition /usr/share/apr-0/build/libtool --silent --mode=link i686-pc-linux-gnu-gcc -o mod_python.la -rpath /usr/lib/apache2/modules -module -avoid-version hlistobject.lo hlist.lo filterobject.lo connobject.lo serverobject.lo util.lo tableobject.lo requestobject.lo _apachemodule.lo mod_python.lo -L/usr/lib/python2.4/config -Xlinker -export-dynamic -lm -lpython2.4 -lpthread -ldl -lutil -lm make[1]: Leaving directory `/var/tmp/portage/mod_python-20050701/work/mod_python-20050701/src' make[1]: Entering directory `/var/tmp/portage/mod_python-20050701/work/mod_python-20050701/dist' ln -s ../lib/python/mod_python ln -s ../src make[2]: Entering directory `/var/tmp/portage/mod_python-20050701/work/mod_python-20050701/src' /usr/local/bin/flex -R -opsp_parser.c --header-file=include/psp_flex.h psp_parser.l make[2]: /usr/local/bin/flex: Command not found make[2]: *** [psp_parser.c] Error 127 make[2]: Leaving directory `/var/tmp/portage/mod_python-20050701/work/mod_python-20050701/src'
This just came on the mod_python list. Please prepare for general bugfix release of mod_python. Actually, I'm using about a month old subversion checkout and it is perfect - those bugs I've hit are fixed. I can only reccomend even that. There were about 2 bugs unfixed at that time, so maybe they manage to fix even those untill the release. Please, don't wait once it comes out and put it ASAP into ~x86 and x86 too. It's really a bugfix release. ------------------ Hi S
This just came on the mod_python list. Please prepare for general bugfix release of mod_python. Actually, I'm using about a month old subversion checkout and it is perfect - those bugs I've hit are fixed. I can only reccomend even that. There were about 2 bugs unfixed at that time, so maybe they manage to fix even those untill the release. Please, don't wait once it comes out and put it ASAP into ~x86 and x86 too. It's really a bugfix release. ------------------ Hi Sébastien, What version of mod_python are you using ? I suppose you're using the 3.1.4and so, yes, there are a few bugs related to multi-threading and module reloadings. A lot of work has been done on mod_python since the 3.1.4release, but until now we haven't managed to make any release, so the bugfixes were only available to those who were adventurous enough to use the latest Subversion version. Anyway, a new 3.2.0-BETA version is currently being prepared and will be available soon (we are making sure that no show-stopping bugs are present in the beta version), so hopefully, you'll be able to use a better version in a few days. FYI, you can access the bug tracking system here : http://issues.apache.org/jira/browse/MODPYTHON Here is the list of bug fixes / improvement that are currently included in the upcoming 3.2.0-BETA version : http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=11060&styleName=Html&projectId=10640&Create=Create If you want to get the latest development version of mod_python, give your Subversion client this URL : https://svn.apache.org/repos/asf/httpd/mod_python/trunk AFAIK the CVS repository mentioned in the homepage is no longer used. It may be synchronized with the Subversion repository, but the reference repository is now under Subversion. Regards, Nicolas
I'm not sure what you're getting at with the rest of the bug report, but your initial `python test.py` _should_ fail. apache can only be imported from mod_python when running within mod_python. * Speaking as a user rather than a dev
Yes, I also figured that out, it can be really imported only from within mod_python.
