#48853 [Bgs]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853 User updated by: leonard-php-bugs at ottolander dot nl Reported By: leonard-php-bugs at ottolander dot nl Status: Bogus Bug Type: Compile Failure Operating System: CentOS-4 PHP Version: 5.2CVS-2009-07-08 (CVS) New Comment: Are you telling me that even though I build the apache module against a newer bundled version of pcre the apache headers still require the old pcre headers to be available? Shouldn't they be using the headers of the newer bundled version of pcre we are building against? Previous Comments: [2010-02-23 23:53:52] sni...@php.net You have deleted required header files and expect _PHP_ to fix it's configure to allow building against 3rd party headers _requiring_ those header files you have deleted, that's is quite insane. It's _APACHE_ requiring the headers, using the headers, needing the headers and linking to the specific library. (Try ldd httpd..) You can't just expect the bundled PCRE the be the correct one, can you? Now, thanks to our broken stuff you have found this problem in your system which you should fix. [2010-02-23 21:58:45] leonard-php-bugs at ottolander dot nl 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. [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? 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=48853edit=1
#48853 [Com]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
Comment by: leonard-php-bugs at ottolander dot nl
Reported By: leonard-php-bugs at ottolander dot nl
Status: No Feedback
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
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.
Previous Comments:
[2009-07-16 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[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 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
#48853 [Fbk-Opn]: Using bundled pcre fails if no unbundled headers are available on the system
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:
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?
Previous Comments:
[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).
[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
#48853 [Fbk-Opn]: Using bundled pcre fails if no unbundled headers are available on the system
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
#48853 [Opn]: Using bundled pcre fails if no unbundled headers are available on the system
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=48853edit=1
#48853 [NEW]: Using bundled pcre fails if no unbundled headers are available on the system
From: leonard-php-bugs at ottolander dot nl Operating system: CentOS-4 PHP version: 5.2CVS-2009-07-08 (CVS) PHP Bug Type: Compile Failure Bug description: Using bundled pcre fails if no unbundled headers are available on the system 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 bug report at http://bugs.php.net/?id=48853edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48853r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48853r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48853r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48853r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48853r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48853r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48853r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48853r=needscript Try newer version: http://bugs.php.net/fix.php?id=48853r=oldversion Not developer issue: http
#48853 [Com]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
Comment by: leonard-php-bugs at ottolander dot nl
Reported By: leonard-php-bugs at ottolander dot nl
Status: Feedback
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
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).
Previous Comments:
[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 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
#40035 [NEW]: [RFE] get_html_translation_table() add option to select character set
From: leonard-php-bugs at ottolander dot nl Operating system: irrelevant PHP version: 4.4.4 PHP Bug Type: Unknown/Other Function Bug description: [RFE] get_html_translation_table() add option to select character set Description: get_html_translation_table() will only return the translation table for the default character set (iso-8859-1). Please add a third option (charset) to get_html_translation_table() to select the translation table for the character sets that are supported by html_entities(). (compare bug 18072) (Actually only tested against php-4.3.9 (CentOS 4) and php-4.3.2 (CentOS 3), but as there is no change in the docs I find it highly unlikely this option has been added in the mean time. If it has I apologize.) -- Edit bug report at http://bugs.php.net/?id=40035edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40035r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40035r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40035r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40035r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40035r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40035r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40035r=needscript Try newer version:http://bugs.php.net/fix.php?id=40035r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40035r=support Expected behavior:http://bugs.php.net/fix.php?id=40035r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40035r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40035r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40035r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40035r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40035r=dst IIS Stability:http://bugs.php.net/fix.php?id=40035r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40035r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40035r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40035r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40035r=mysqlcfg
#40035 [Opn]: get_html_translation_table() ignores locale + [RFE] option to override charset
ID: 40035 User updated by: leonard-php-bugs at ottolander dot nl -Summary: [RFE] get_html_translation_table() add option to select character set Reported By: leonard-php-bugs at ottolander dot nl Status: Open Bug Type: Unknown/Other Function Operating System: irrelevant -PHP Version: 4.4.4 +PHP Version: 5.2.0 New Comment: Looking at the source of php-5.2.0 I get the impression get_html_translation_table() actually ignores any locale settings: PHP_FUNCTION(get_html_translation_table): enum entity_charset charset = determine_charset(NULL TSRMLS_CC); static enum entity_charset determine_charset(char *charset_hint TSRMLS_DC): /* Guarantee default behaviour for backwards compatibility */ if (charset_hint == NULL) return cs_8859_1; If I am reading the above correctly determine_charset() will always return cs_8859_1 to get_html_translation_table() as the latter passes NULL as the charset_hint. So it's not only not possible to override the charset when returning the translation table (which might be useful when handling data that does not use the same charset as the system), it seems the function totally ignores the system locale. Previous Comments: [2007-01-05 17:40:31] leonard-php-bugs at ottolander dot nl Description: get_html_translation_table() will only return the translation table for the default character set (iso-8859-1). Please add a third option (charset) to get_html_translation_table() to select the translation table for the character sets that are supported by html_entities(). (compare bug 18072) (Actually only tested against php-4.3.9 (CentOS 4) and php-4.3.2 (CentOS 3), but as there is no change in the docs I find it highly unlikely this option has been added in the mean time. If it has I apologize.) -- Edit this bug report at http://bugs.php.net/?id=40035edit=1
