|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2001-12-10 08:51 UTC] vogel at folz dot de
We have a virtual host here where the include_path varies per directory. We configure this in the Apache config (php as a DSO module) like this: <Directory /var/www/html/dir1> php_value include_path ".:/var/www/html/dir1/lib" </Directory> <Directory /var/www/html/dir2> php_value include_path ".:/var/www/html/dir2/lib" </Directory> (and many more) We have tried this with many versions of Apache 1.3.x and php-4.0.x (up to apache-1.3.22 / php-4.1.0RC3) and all combinations exhibit the same problem: If there are two or more concurrent users that access different directories of this virtual host, one or more of them get pages with php errors, because the php scripts don't get the include files they need. The error messages show clearly that the include files were searched via a wrong include_path, i.e. one out of the other <Directory ..> sections of the same virtual host. We used both standard Redhat 7.x apache and php RPMs, as well as self-compiled RPMs based on Redhat's SRPMs, all with the same result/problem. If you need more specific information, please ask. PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Oct 24 14:00:01 2025 UTC |
There is another bug w/ include_path (#15374), and a temporary work around was to put this before any include: ini_set('include_path', ini_get('include_path')); Though if you have problems with prepend files, there probably isn't any place you could put this where it would get executed in time. =/When I said "show stopper" I meant "installation failed", hence I don't know if this fixes the include_path problem. The IMAP part of configure works half way: It detects that SSL libraries are needed for c-client, but the build test fails. The end of config.log reads: configure:34926: checking whether SSL libraries are needed for c-client configure:35086: checking whether IMAP works configure:35119: gcc -o conftest -O2 -march=i386 -mcpu=i686 -fPIC -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib conftest.c -lcrypt -lpam -lgmp -lgd -lttf -lX11 -lXpm -lpng -lz -ljpeg -ldb -lgdbm -lbz2 -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcrypt 1>&5 /tmp/cc8QGtUw.o: In function `main': /tmp/cc8QGtUw.o(.text+0x112): undefined reference to `mail_open' collect2: ld returned 1 exit status configure: failed program was: #line 35094 "configure" #include "confdefs.h" void mm_log(void){} void mm_dlog(void){} void mm_flags(void){} void mm_fatal(void){} void mm_critical(void){} void mm_nocritical(void){} void mm_notify(void){} void mm_login(void){} void mm_diskerror(void){} void mm_status(void){} void mm_lsub(void){} void mm_list(void){} void mm_exists(void){} void mm_searched(void){} void mm_expunged(void){} char mail_open(); int main() { mail_open(0,"",0); return 0; } See, there's no -lc-client. I even did a "IMAP_SHARED_LIBADD=-lc-client ; export IMAP_SHARED_LIBADD" before calling configure and nothing changed.... I had various other build problems until I removed the --disable-rpath option from configure (--disable-rpath was there for "historical" reasons, read: because redhat used it in their spec file). The PEAR installation fails right at it's start: $ make install INSTALL_ROOT=/var/tmp/php-root [/bin/sh libtool command omitted for brevity] Installing PHP SAPI module Installing shared extensions: /var/tmp/php-root/usr/lib/php4/ Installing PHP CLI binary: /var/tmp/php-root/usr/bin/ Installing PEAR environment: /var/tmp/php-root/usr/share/pear/ Warning: SAFE MODE Restriction in effect. The script whose uid is 503 is not allowed to access /usr/share owned by uid 0 in /home/vogel/rpm/BUILD/php4-200207170600/pear/System.php on line 235 This last message is repeated _many_ times, with some "Warning: version_compare() expects parameter 2" messages interspersed. I can reproduce this in various ways (i. e. building using rpm or doing the same "by hand"; changing configure options did not help in any way). If you want to reproduce: environment is redhat linux 7.0 with all relevant updates from redhat installed. I don't want to build with a newer redhat release, because the target server, where the binary will get installed finally, has redhat 7.0, too (and -- you guess it -- I cannot update to a newer release because that's a "production" machine). And yes, ext/pgsql in snapshot 200207170600 builds. If you're interested, I can send you a complete log of the rpm build via email. I don't want to include it here because of it's size (over 500 kByte).