#48853 [Opn->Fbk]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853 Updated by: sni...@php.net Reported By: leonard-php-bugs at ottolander dot nl -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: CentOS-4 PHP Version: 5.2CVS-2009-07-08 (CVS) New Comment: 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.. Previous Comments: [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 unus
#48853 [Opn->Fbk]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853 Updated by: j...@php.net Reported By: leonard-php-bugs at ottolander dot nl -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: CentOS-4 PHP Version: 5.2CVS-2009-07-08 (CVS) New Comment: "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.. Previous Comments: [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). [2009-07-08 20:37:17] j...@php.net And your configure line is..? [2009-07-08 14:17:45] leonard-php-bugs at ottolander dot nl Description: Building 5.2.9 on CentOS-4, although later versions until CVS today are affected. The OS is not really relevant, just the reason there are no unbundled headers available as there's a version mismatch with the bundled headers. Using the bundled pcre library by not supplying any pcre c
#48853 [Opn->Fbk]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853 Updated by: j...@php.net Reported By: leonard-php-bugs at ottolander dot nl -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: CentOS-4 PHP Version: 5.2CVS-2009-07-08 (CVS) New Comment: And your configure line is..? Previous Comments: [2009-07-08 14:17:45] leonard-php-bugs at ottolander dot nl Description: Building 5.2.9 on CentOS-4, although later versions until CVS today are affected. The OS is not really relevant, just the reason there are no unbundled headers available as there's a version mismatch with the bundled headers. Using the bundled pcre library by not supplying any pcre configure options. When the unbundled (upgraded/matching) headers are available on the system the build succeeds. However, if no unbundled headers are available httpd.h cannot find the bundled pcreposix.h (and other headers). This is *not* an apache issue, the issue is a missing include path in the build. If you compare ext/pcre/config0.m4 an include path is provided in case of an external pcre (although on CentOS it will be found in /usr/include no matter if a path is specifically provided): if test "$PHP_PCRE_REGEX" != "no"; then if test "$PHP_PCRE_REGEX" = "yes"; then ... (no PHP_ADD_INCLUDE here) else ... PHP_ADD_INCLUDE($PCRE_INCDIR) ... fi Fix with this patch which provides the include path (ignore the line wraps, it's just a single line addition): --- php-5.2.9/ext/pcre/config0.m4.000 2008-12-29 16:27:11.0 +0100 +++ php-5.2.9/ext/pcre/config0.m4 2009-07-08 13:27:11.0 +0200 @@ -13,6 +13,7 @@ if test "$PHP_PCRE_REGEX" != "no"; then if test "$PHP_PCRE_REGEX" = "yes"; then PHP_NEW_EXTENSION(pcre, pcrelib/pcre_chartables.c pcrelib/pcre_ucd.c pcrelib/pcre_compile.c pcrelib/pcre_config.c pcrelib/pcre_exec.c pcrelib/pcre_fullinfo.c pcrelib/pcre_get.c pcrelib/pcre_globals.c pcrelib/pcre_info.c pcrelib/pcre_maketables.c pcrelib/pcre_newline.c pcrelib/pcre_ord2utf8.c pcrelib/pcre_refcount.c pcrelib/pcre_study.c pcrelib/pcre_tables.c pcrelib/pcre_try_flipped.c pcrelib/pcre_valid_utf8.c pcrelib/pcre_version.c pcrelib/pcre_xclass.c php_pcre.c, $ext_shared,,-...@ext_srcdir@/pcrelib) PHP_ADD_BUILD_DIR($ext_builddir/pcrelib) +PHP_ADD_INCLUDE([$ext_srcdir/pcrelib]) PHP_INSTALL_HEADERS([ext/pcre], [php_pcre.h pcrelib/]) AC_DEFINE(HAVE_BUNDLED_PCRE, 1, [ ]) else Reproduce code: --- Make sure you REMOVE any unbundled pcre headers from the system. /usr/include is in the include path and thus the necessary unbundled headers will be found so you wont see the build fail. Configure without any pcre related options to use the bundled version. Expected result: Headers found, build succeeds. It does with the patch. Actual result: -- /bin/sh /usr/src/redhat/BUILD/php-5.2.9/build-apache/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/include/httpd -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apr-0 -I/usr/include/apr-0 -Isapi/apache2handler/ -I/usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/ -DPHP_ATOM_INC -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/include -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/main -I/usr/src/redhat/BUILD/php-5.2.9 -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/ext/date/lib -I/usr/src/redhat/BUILD/php-5.2.9/ext/date/lib -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/TSRM -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/Zend -I/usr/src/redhat/BUILD/php-5.2.9/main -I/usr/src/redhat/BUILD/php-5.2.9/Zend -I/usr/src/redhat/BUILD/php-5.2.9/TSRM -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/-I/usr/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -fno-strict-aliasing -prefer-pic -c /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c -o sapi/apache2handler/mod_php5.lo In file included from /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/php_apache.h:24, from /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 make: *** [sapi/apache2handler/mod_php5.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=48853&edit=1