ID: 48853 User updated by: leonard-php-bugs at ottolander dot nl Reported By: leonard-php-bugs at ottolander dot nl Status: Open Bug Type: Compile Failure Operating System: CentOS-4 PHP Version: 5.2CVS-2009-07-08 (CVS) New Comment:
Btw, I'm not saying the proposed patch is the best place to fix this. You might want to fix this missing include path around where the option --with-apxs2 is parsed and set the include path there in case we build against the bundled pcre. But again, since only PHP knows the path to it's own bundled pcre headers it's PHP's task to make the path to those bundled headers available. Previous Comments: ------------------------------------------------------------------------ [2010-02-23 21:37:54] leonard-php-bugs at ottolander dot nl The issue is that the apache headers that you include in the module build expect the pcre headers in one of the default locations. Since we build against the pcre library that you bundle you should provide that extra path to those headers. You cannot expect apache to look for them in an unknown build path and an unknown subdiretory. ------------------------------------------------------------------------ [2010-02-23 19:59:38] sni...@php.net Considering the error really happens inside Apache headers, how is this a PHP bug? From your compile error: /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c:26: /usr/include/httpd/httpd.h:43:23: pcreposix.h: No such file or directory Blindly adding unnecessary include paths to fix something outside our control is not very wise.. ------------------------------------------------------------------------ [2010-02-23 17:15:34] leonard-php-bugs at ottolander dot nl I narrowed the offending configure option down to --with-apxs2=/usr/sbin/apxs Afaik I need to specify that option to build the apache module... Or am I mistaken? ------------------------------------------------------------------------ [2010-02-23 15:29:09] j...@php.net "no feedback" means you didn't provide the feedback from the correct tab but failed and used "Add Comment" instead (the right place is "Edit Submission" for you since you reported this). Now, can you please provide the actual configure line? Something I can copy'n'paste and which has ONLY the required options to reproduce this. Note: I can not reproduce this with or without the pcre headers around.. ------------------------------------------------------------------------ [2010-02-23 14:18:28] leonard-php-bugs at ottolander dot nl I am unsure why this report was labeled "No Feedback" as I provided the requested configure line within 2 hours after the request was made. I was not aware of this state change as I haven't received an email indicting this. Doing a quick checkup in SVN it seems this issue was not fixed. In 5.3.2 the block where $PHP_PCRE_REGEX" = "yes" tests true got moved to the bottom of the file, but the required include path still seems not to be provided. To shortly restate the issue: On a system where no other pcre headers are available the headers of the bundled pcre are not found due to a missing include path and the build fails. Since on most systems pcre headers will be available you will need to explicitly remove the pcre headers provided by the build system (pcre-devel package or similar) to reproduce this issue. If any other pcre headers than the bundled ones are available on the system the build will use those and succeed where it shouldn't. Build still fails on CentOS(/RHEL)-4 for php-5.2.12. Old headers have been removed using rpm -e --nodeps pcre-devel. I am aware this is an unusual situation, but what is the point of building against the bundled pcre source when the build uses the (old and wrong) headers provided by the build system? PHP should find and use the headers of the bundled pcre when building against these, not some random headers available on the system. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48853 -- Edit this bug report at http://bugs.php.net/?id=48853&edit=1