Currently we have an open bug #16809 (http://pecl.php.net/bugs/bug.php?id=16809&edit=1) in APC where we're unable to find the pcre.h header file as it's not in our include path when a user compiles PHP with the --enable-pcre=<some include path>. This is because the include path the user provides isn't made available in INCLUDES in the extension (APC) when compiled as a shared library using phpize.
I've come up with the following solution, but want feedback/other options before I commit. Essentially I've made use of the EXTRA_INCLUDES that's included in INCLUDES, but not really used much of anywhere AFAIK. I've also added the autoconf macro PHP_ADD_EXTRA_INCLUDE that mirrors the PHP_ADD_INCLUDE behavior, as well as the --extra_includes option to php-config. This way extensions can provide additional include paths that they depend on for extensions that may in-turn be dependent on their header files.
http://tekrat.com/downloads/bits/extra_includes.php5.3.patch
Interested in hearing other options on how this can be corrected, or feedback on this approach...
Thanks,
-shire
hi!
Currently we have an open bug #16809
(http://pecl.php.net/bugs/bug.php?id=16809&edit=1) in APC where we're unable
to find the pcre.h header file as it's not in our include path when a user
compiles PHP with the --enable-pcre=<some include path>. This is because
the include path the user provides isn't made available in INCLUDES in the
extension (APC) when compiled as a shared library using phpize.I've come up with the following solution, but want feedback/other options
before I commit. Essentially I've made use of the EXTRA_INCLUDES that's
included in INCLUDES, but not really used much of anywhere AFAIK. I've also
added the autoconf macro PHP_ADD_EXTRA_INCLUDE that mirrors the
PHP_ADD_INCLUDE behavior, as well as the --extra_includes option to
php-config. This way extensions can provide additional include paths that
they depend on for extensions that may in-turn be dependent on their header
files.http://tekrat.com/downloads/bits/extra_includes.php5.3.patch
Would it be not more correct to test if the bundled pcre is used or
not. And detect the pcre header if the system pcre is used?
Cheers,
Pierre
Heya,
Pierre Joye wrote:
hi!
Currently we have an open bug #16809
(http://pecl.php.net/bugs/bug.php?id=16809&edit=1) in APC where we're unable
to find the pcre.h header file as it's not in our include path when a user
compiles PHP with the --enable-pcre=<some include path>. This is because
the include path the user provides isn't made available in INCLUDES in the
extension (APC) when compiled as a shared library using phpize.I've come up with the following solution, but want feedback/other options
before I commit. Essentially I've made use of the EXTRA_INCLUDES that's
included in INCLUDES, but not really used much of anywhere AFAIK. I've also
added the autoconf macro PHP_ADD_EXTRA_INCLUDE that mirrors the
PHP_ADD_INCLUDE behavior, as well as the --extra_includes option to
php-config. This way extensions can provide additional include paths that
they depend on for extensions that may in-turn be dependent on their header
files.http://tekrat.com/downloads/bits/extra_includes.php5.3.patch
Would it be not more correct to test if the bundled pcre is used or
not. And detect the pcre header if the system pcre is used?
We can definitely check to see if PCRE is bundled or not, but how do we detect the exact path of the pcre.h file that was used? (we could also have multiple pcre.h files on the same system), so it seems we need to store this somewhere in the PHP configuration that the shared extension can pull from. My thinking here was that just making it part of the existing INCLUDE path was easiest, we could probably make this some sort of macro that the extension has to explicitly call to get this path included as well. Perhaps that's more ideal so we don't get a bunch of extra include paths we don't actually need for other extensions?
I'm not sure I follow the openssl/libxml examples entirely, as this case would be us depending on having a way for an extension like APC to get the location of openssl includes/lib paths. Do we have that scenario somewhere?
Thanks!
-shire
hi,
We can definitely check to see if PCRE is bundled or not, but how do we
detect the exact path of the pcre.h file that was used? (we could also have
multiple pcre.h files on the same system), so it seems we need to store this
somewhere in the PHP configuration that the shared extension can pull from.
If the flag for the bundled PCRE is set, the include path should be
set to php's include directory, or to the system pcre if not.
The problem is when the system PCRE is installed in the default prefix
just like any other libs and php was built with the bundled PCRE. In
this case you can just hope that php's include is first in the list,
but this configuration is a call for troubles and should not be
supported (we bogus'ed some bugs about that afair).
My thinking here was that just making it part of the existing INCLUDE path
was easiest, we could probably make this some sort of macro that the
extension has to explicitly call to get this path included as well. Perhaps
that's more ideal so we don't get a bunch of extra include paths we don't
actually need for other extensions?I'm not sure I follow the openssl/libxml examples entirely, as this case
would be us depending on having a way for an extension like APC to get the
location of openssl includes/lib paths. Do we have that scenario somewhere?
A PHP_SETUP_PCRE could do all the jobs for you. Then you would only
have to use something like:
PHP_SETUP_PCRE(APC_SHARED_LIBADD,
[
AC_DEFINE(HAVE_PCRE_EXT,1,[ ])
], [
AC_MSG_ERROR([OpenSSL check failed. Please check config.log for
more information.])
])
By the way, given that PCRE is enabled by default in 5.3+ (maybe in
5.2 too, I don't rememer :), I don't see it as a dependency. Maybe APC
could add an extension depency and use ext/pcre's exposed API (which
implements the cache as well).
Cheers,
Pierre