Re: --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