ID: 48853
User updated by: leonard-php-bugs at ottolander dot nl
Reported By: leonard-php-bugs at ottolander dot nl
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2009-07-08 22:29:16] leonard-php-bugs at ottolander dot nl
As I said, I'm not using a --with- or --without-pcre option. The other
options seem not very relevant in this context but I'll paste the line
from the used rpm spec file here. %configure translates to configure ;)
%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--without-mime-magic \
--without-sqlite \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
$*
I'd say, just open ext/pcre/config0.m4 and see there's no
PHP_ADD_INCLUDE inside the second (nested) if that causes httpd.h to be
unable to locate pcreposix.h if no pcre headers are installed on the
system.
If there is already a local copy of the pcre headers installed the
-I/usr/include will cause the build to still find a (possible incorrect)
version of the headers, and it succeeds (if the versions are close
enough).
On my system these headers aren't available as on CentOS-4 they are
version 4.5, so I removed them. This is an unusual situation, which is
probably why nobody noticed this issue before (the local headers are
probably available on most systems because builds like apache depend on
them).
------------------------------------------------------------------------
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
