--with-ereg

Steph Fox wrote:

For PHP 5.3, you get browscap.obj linking errors. I don't
understand what ereg does, but I found I had to add the option:

--with-ereg

Is this option a new required minimal build option that should be forced?

'This ereg stuff' is important, in that it supports legacy code... it
moved from ext/standard to ext/ereg in 5_3 in the vague hope that it
might be possible to move it out to PECL some day. But whoever did it
obviously missed a bit.

Again, though... you're seeing errors I don't see.

ok, thats good.

So just to confirm (to avoid goose chasing <g>) you are saying you tried
the minimal build options:

--disable-all
--enable-cli
--enable-cgi
--enable-object-out-dir=.
--disable-ipv6.

and the current PHP 5.3 CVS built correctly, without errors?

I did trace it down the other day and the compiling errors make sense:

With the above options, the corresponding global

 PHP_EREG is "no"

So the ext\ereg\config.w32 logic is not applied and the new (moved)
ext/ereg/regex folder is never set. Since it was always off the root
folder, it was always found. But no mas.

Hence

REGEX
HSREGEX

are never defined nor set to zero.

However, they are hard coded in:

main\config.w32.h

#define REGEX 1
#define HSREGEX 1

and there is no way possible to ever set these to zero.

Hence browscap.h will get a compiler error because it is attempting
include the regex.h here with no /I include path never set.

So I noticed the movement of the regex\ folder to ext\ereg\regex folder
and the first thing I did was add /I ext\ereg\regex as part of the
makefile BASE_INCLUDE:

BASE_INCLUDES=/I . /I main /I Zend /I TSRM /I ext /I ext\ereg\regex.

I don't know yet if this is correct, but I'm just checking to see what
happens next.

Now browscap.c finds it but you have unresolved links to the php_reg*
stuff like so:

ereg.obj : error LNK2019: unresolved external
           symbol php_regcomp referenced in function _php_regcomp
browscap.obj : error LNK2001: unresolved external symbol php_regcomp

Of course, they the extension was never compiled. Its a minimal build.

So I figured, "Ok, why is browscap needed anyway? And what is the
alternative to when REGEX is set to 0?

So lets try that, after all, its hardcoded and maybe it should be turned
off. So I explored changing ext\ereg\config.w32 to do:

if (PHP_EREG != "no") {
...
} else {
ADD_SOURCES("ext/ereg/regex", "regcomp.c regexec.c
regerror.c regfree.c", "ereg");
AC_DEFINE('REGEX', 0, 'System Bundled regex');
ADD_FLAG("STATIC_EXT_OBJS", "$(EREG_GLOBAL_OBJS)");
}

to see what happens when REGEX is set to ZERO in

main\config.w32.h

I was just winging it, but I forget now, browscap.c was simply never
designed to be compiled without REGEX and I didn't enough about to begin
breaking things.

So I stopped and looked at the options. I found the following
differences in the old 5.2 and 5.3 configure.js help

File: D:\phpdev\php52\configure-help.txt

 --enable-mbregex               multibyte regex support
 --disable-mbregex-backtrack    check multibyte regex backtrack
 --without-pcre-regex           Perl Compatible Regular Expressions

File: D:\phpdev\php53\configure-help.txt

 --enable-mbregex              multibyte regex support
 --disable-mbregex-backtrack   check multibyte regex backtrack
 --without-ereg                POSIX extended regular expressions

and went with:

 --with-ereg

and it worked.

So I can't see how it worked for in 5.3 with this off. Browscap.c will
died. :-)

I'll be happy to patch it but I honestly don't know enough about its
design or purpose. I did know about some Browscap.ini file and I
figured it is related to that. Buts that's about it.

The real question I had when I was going thru all this is why isn't
configure.js turning off defines if something isn't set.

--
Hector Santos