Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37748
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain isdg.net designates 208.247.131.9 as permitted sender)
Message-ID: <4832F125.2040704@isdg.net>
Date: Tue, 20 May 2008 11:41:25 -0400
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Steph Fox <steph@zend.com>
CC: internals <internals@lists.php.net>, 
 Elizabeth M Smith <auroraeosrose@shitennou.com>
References: <4832DDC5.7060307@isdg.net> <014f01c8ba86$9ec2ce10$4401a8c0@foxbox>
In-Reply-To: <014f01c8ba86$9ec2ce10$4401a8c0@foxbox>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: --with-ereg
From: hsantos@isdg.net (Hector Santos)

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