Heya,
as a distribution we usually aim at using system libraries instead of
bundled ones, both for security and maintainance reasons.
PHP bundles liboniguruma (ext/mbstring/oniguruma) and currently does not
allow for using an external copy of the lib.
I hacked up a patch [1] which adds a new configure switch
(--with-onig-dir) and builds against the system lib accordingly.
It would be nice if it could get included in the official sources.
Should be rather as easy as this patch should not (well, I tried, but
who knows) break backwards compatibility.
Even if it won't get included, I guess it's still useful to post it here
so that other packagers can grab it as well. ;o)
[1] https://bugs.gentoo.org/attachment.cgi?id=151781&action=view
--
Christian Hoffmann
Hi Christian,
Am Sonntag, den 04.05.2008, 12:14 +0200 schrieb Christian Hoffmann:
[...]
as a distribution we usually aim at using system libraries instead of
bundled ones, both for security and maintainance reasons.
PHP bundles liboniguruma (ext/mbstring/oniguruma) and currently does not
allow for using an external copy of the lib.
I hacked up a patch [1] which adds a new configure switch
(--with-onig-dir) and builds against the system lib accordingly.
It would be nice if it could get included in the official sources.
Should be rather as easy as this patch should not (well, I tried, but
who knows) break backwards compatibility.
Even if it won't get included, I guess it's still useful to post it here
so that other packagers can grab it as well. ;o)
Could you provide the patch for HEAD as well? I don't see a reason not
to include it.
cu, Lars
Hi,
sorry for the late response, was really busy the last days.
Am Sonntag, den 04.05.2008, 12:14 +0200 schrieb Christian Hoffmann:
[...]as a distribution we usually aim at using system libraries instead of
bundled ones, both for security and maintainance reasons.
PHP bundles liboniguruma (ext/mbstring/oniguruma) and currently does not
allow for using an external copy of the lib.
I hacked up a patch [1] which adds a new configure switch
(--with-onig-dir) and builds against the system lib accordingly.
It would be nice if it could get included in the official sources.
Should be rather as easy as this patch should not (well, I tried, but
who knows) break backwards compatibility.
Even if it won't get included, I guess it's still useful to post it here
so that other packagers can grab it as well. ;o)Could you provide the patch for HEAD as well? I don't see a reason not
to include it.
I ported the patch, but immediately noticed that while trying to test it:
$ ./configure --disable-all --enable-mbstring --disable-cgi --enable-cli
--with-pcre-regex=yes
checking whether to enable multibyte string support... yes
checking whether to enable multibyte regex support... yes
checking for external libmbfl... no
configure: error: multibyte regex support must be disabled, use
--disable-mbregex
Relevant code from ext/mbstring/config.m4:
275 if test "$PHP_MBREGEX" != "no"; then
276 AC_MSG_ERROR([multibyte regex support must be disabled, use
--disable-mb regex])
Apparently mbregex is not supported in HEAD and as such there is no need
for oniguruma at all, is there?
Maybe it was simply forgotten to re-enable it (apparently it was
disabled for <HEAD for some time, too).
So, will mbregex be re-enabled in HEAD? If yes, then I'll be happy to
create the patch, otherwise, the whole oniguruma stuff should probably
be dropped.
On a different note, --disable-all seems to behave a bit strange in case
of PCRE:
$ ./configure --disable-all --disable-cgi --enable-cli
checking for PCRE support... no
configure: error: Could not find pcre.h in no
This is really confusing, either it should be allowed to disable PCRE as
it used to be in 5_2 (i.e. making "no" meaning no and not be interpreted
as a path) or always default to "yes" if no path was given.
--
Christian Hoffmann
Gentoo PHP team
Hi Christian,
Am Samstag, den 17.05.2008, 22:36 +0200 schrieb Christian Hoffmann:
[...]
Relevant code from ext/mbstring/config.m4:
275 if test "$PHP_MBREGEX" != "no"; then
276 AC_MSG_ERROR([multibyte regex support must be disabled, use
--disable-mb regex])
[...]
So, will mbregex be re-enabled in HEAD? If yes, then I'll be happy to
create the patch, otherwise, the whole oniguruma stuff should
probably
be dropped.
I would guess that it's due to general unicode support. But it would be
interesting to know, if the assumption is correct. Another sidenote:
Illia, would you like to have this patch for 5_2?
On a different note, --disable-all seems to behave a bit strange in
case of PCRE:
$ ./configure --disable-all --disable-cgi --enable-cli
checking for PCRE support... no
configure: error: Could not find pcre.h in noThis is really confusing, either it should be allowed to disable PCRE
as it used to be in 5_2 (i.e. making "no" meaning no and not be
interpreted as a path) or always default to "yes" if no path was
given.
That's indeed not optimal. But if ext/mbstring is removed completely, it
won't be a problem really. Can someone clarify the plans for HEAD and
mbstring?
cu, Lars