When I build php5.2.8-r2 with pcre - useflag, libpcre7.8 is emerged first and php is built with --with-pcre-dir=/usr. When I afterwards use phpinfo() to get php info, I see pcre 3.9 (!!) and my apps fail with all kinds of pcre related errors: PCRE (Perl Compatible Regular Expressions) Support enabled PCRE Library Version 3.9 02-Jan-2002 Reproducible: Always Steps to Reproduce: 1. emerge php 2. php phpinfo() Actual Results: if any, php is working with pcre 3.9 Expected Results: php should be running with pcre 7.8 since php5.2.8, php is coming with libpcre7.8 bundled. If you remove the --with-pcre-dir=/usr, php5.2.8 will still be running with libpcre 7.8 and all will be fine. I patched the php5.2.8-r2 ebuild to get this done: 280,283c280,283 < if use pcre || phpconfutils_usecheck pcre ; then < myconf="${my_conf} --with-pcre-dir=/usr" < phpconfutils_extension_with "pcre-regex" "pcre" 0 "/usr" < fi --- > # if use pcre || phpconfutils_usecheck pcre ; then > # myconf="${my_conf} --with-pcre-dir=/usr" > # phpconfutils_extension_with "pcre-regex" "pcre" 0 "/usr" > # fi 349,352c349,352 < if use pcre || phpconfutils_usecheck pcre ; then < myconf="${my_conf} --with-pcre-dir=/usr" < phpconfutils_extension_with "pcre-regex" "pcre" 0 "/usr" < fi --- > # if use pcre || phpconfutils_usecheck pcre ; then > # myconf="${my_conf} --with-pcre-dir=/usr" > # phpconfutils_extension_with "pcre-regex" "pcre" 0 "/usr" > # fi Here are my useflags: php5.2.8-r2: USE="apache2 berkdb bzip2 cli crypt ctype curl exif ftp gd gdbm gmp iconv imap json ldap mysql ncurses nls pcre pdo readline reflection session simplexml snmp soap spl ssl tidy truetype unicode xml zlib (-adabas) -bcmath (-birdstep) -calendar -cdb -cgi -cjk -concurrentmodphp -curlwrappers -db2 -dbase (-dbmaker) -debug -discard-path -doc (-empress) (-empress-bcs) (-esoob) -fastbuild (-fdftk) -filter (-firebird) -flatfile -force-cgi-redirect (-frontbase) -gd-external -hash -inifile -interbase -iodbc -ipv6 (-java-external) -kerberos -kolab -ldap-sasl -libedit -mcve -mhash -msql -mssql -mysqli -oci8 -oci8-instant-client -odbc -pcntl -pic -posix -postgres -qdbm -recode -sapdb -sharedext -sharedmem -sockets (-solid) -spell -sqlite -suhosin (-sybase) (-sybase-ct) -sysvipc -threads -tokenizer -wddx -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zip-external" libpcre-7.8 USE="bzip2 cxx unicode zlib -doc"
Your fix would be incorrect. Those blocks were put there to fix a certain problem that happened due to bundled pcre. And anyway, it should work, check the output of 'ldd /usr/lib/apache2/modules/libphp5.so' perhaps you've got a stale lib somewhere.
I thought the switch to external pcre was done because of this?: PHP ships a vulnerable version of the PCRE library which allows for the circumvention of security restrictions or even for remote code execution in case of an application which accepts user-supplied regular expressions (CVE-2008-0674). This should be solved in php5.2.8 by using libpcre 7.8 as the bundled one. Yes, ldd /usr/lib/apache2/modules/libphp5.so shows libpcre.so.0 => /usr/lib/libpcre.so.0 (0x00007fb3f0089000) But still pcre doesn't work in apache/php. I have it on about 60 Machines with amd64 using 2007.0 and 2008.0 both amd64 and x86.
No, the reason was bug 238127.
I'm going to make a wild guess here and say: You're running a version of apache that is no longer in portage. Those versions have their own internal copy of libpcre, causing symbol collisions. All versions of php and apache will from now on use external libpcre to avoid these kinds of problems.
Link to a forum thread where we debugged this problem: http://forums.gentoo.org/viewtopic-t-723800.html
I'm pretty sure this can be closed?
(In reply to comment #4) > I'm going to make a wild guess here and say: You're running a version of apache > that is no longer in portage. Those versions have their own internal copy of > libpcre, causing symbol collisions. All versions of php and apache will from > now on use external libpcre to avoid these kinds of problems. Yep, I'd have said this as well. Still, as we cannot be sure, I'll close the bug as WORKSFORME. So, please make sure you are using a recent enough version of Apache. If you still think you have encountered a different issue, please reopen the bug. BTW: The motivations for switching (back) to the system PCRE was mainly because of one specific issue (as loki_val already said) and because of security/maintainability concerns. And we're very unlikely to revert this step, unless there are any severe problems, as I consider this a great improvement otherwise...
Sorry for the late response. Yes, you are right, we are still with apache 2.0.58. Although the 2.0 branch of apache is not in portage anymore, maybe there could be a USE-Flag to control which pcre is to be used? Anyway, maybe there should be at least a dependency for apache >=2.2 in the ebuild?
+1 as a dev for needing it, because I've got a box on Apache 2.0 still as well (due to a third party module *grumbles*).
I don't see what we could do here. I won't add a php version with internal pcre support anymore -- it will be a nightmare for the security team to enumerate the different configurations. It's already hard enough in case of PHP now, so I don't want to make it even worse. I guess the best solution would be to make your apache version use the system copy of pcre as well, which might not be easy either. The situation is: breakage with inofficial packages (which are no longer in the tree), where the fix for it would cause breakage (or well, rather yet another suboptimal state) for official packages. So I prefer not to change anything in portage. I'm sorry, but I will close this as WONTFIX for our official tree, as we cannot fix it without introducing new (or old) "problems" (security-wise, bundling of pcre in php).
