[PHP MapScript] Problem with regex when PHP compiled as a module

[dmorissette]

Jean-Francois.Doyon@ccrs.nrcan.gc.ca wrote:
> G'Day,
> 
> Daniel mentionned to me that thread safty should be fairly complete, though
> untested, in CVS.
> 
> So, I'm trying to compile MapServer CVS with PHP 4.3.3, with all of them as
> modules.
> 
> Not having much luck though!
> 
> First MapServer seems to mis-detect the regex setting on my PHP, even though
> it's compiled with --with-regex=system, I get ugly errors (See at the end of
> this message).  Apparently "configure" tests for the existence of "define
> REGEX 1" ... The funny thing is that this is true whether I compile PHP with
> "system" or "php" regex's !! The only way for this NOT to be true so far is
> to use the "apache" regex setting ... Which I didn't do.
> 
> For now I've hacked the configure script to pretend like the test works,
> even when it doesn't :)
> 
> Any ideas on what's going on here ? Is the PHP regex implementation
> sensitive to whether it's a module or not maybe ? Could I use "apache" for
> now, if only just for testing ?
> 
> I haven't gotten there yet, but I've also obviously hacked the test for apxs
> to by-pass that.  I've built mapserver with --with-threads also.  Will this
> be enough ?
> 
> Any insight would be much appreciated :)
> 
> Here's the regex related error when using --with-regex=system and bypassing
> the test in configure:
> 
> ...
> gcc -fPIC -O2  -Wall -DCOMPILE_DL=1 -DPHP4 -DUSE_WMS_LYR   -DUSE_WMS_SVR
> -DUSE_GDAL -DUSE_OGR   -DUSE_THREAD -DUSE_PROJ -DUSE_PROJ_API_H -DUSE_EPPL
> -DUSE_TIFF   -DUSE_GD_GIF -DUSE_GD_PNG -DUSE_GD_JPEG -DUSE_GD_WBMP
> -DUSE_GD_FT -DGD_HAS_GDIMAGEGIFPTR -DUSE_JPEG  -I/usr/src/mapserver
> -I/usr/local/include     -I/usr/local/include -I/usr/local/include
> -I/usr/local/include   -I/usr/src/mapserver/../php-4.3.3/
> -I/usr/src/mapserver/../php-4.3.3//dl
> -I/usr/src/mapserver/../php-4.3.3//main
> -I/usr/src/mapserver/../php-4.3.3//Zend
> -I/usr/src/mapserver/../php-4.3.3//include
> -I/usr/src/mapserver/../php-4.3.3//TSRM  -c -o php_mapscript.o
> php_mapscript.c
> In file included from /usr/src/mapserver/../php-4.3.3/main/php_regex.h:13,
>                  from /usr/src/mapserver/../php-4.3.3/main/php.h:74,
>                  from php_mapscript_util.h:58,
>                  from php_mapscript.c:218:
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:33: warning: `REG_EXTENDED'
> redefined
> /usr/include/regex.h:257: warning: this is the location of the previous
> definition
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:34: warning: `REG_ICASE'
> redefined
> /usr/include/regex.h:261: warning: this is the location of the previous
> definition
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:35: warning: `REG_NOSUB'
> redefined
> /usr/include/regex.h:270: warning: this is the location of the previous
> definition
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:36: warning: `REG_NEWLINE'
> redefined
> /usr/include/regex.h:266: warning: this is the location of the previous
> definition
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:67: warning: `REG_NOTBOL'
> redefined
> /usr/include/regex.h:280: warning: this is the location of the previous
> definition
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:68: warning: `REG_NOTEOL'
> redefined
> /usr/include/regex.h:283: warning: this is the location of the previous
> definition
> In file included from /usr/src/mapserver/../php-4.3.3/main/php_regex.h:13,
>                  from /usr/src/mapserver/../php-4.3.3/main/php.h:74,
>                  from php_mapscript_util.h:58,
>                  from php_mapscript.c:218:
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:17: conflicting types for
> `regoff_t'
> /usr/include/regex.h:399: previous declaration of `regoff_t'
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:23: conflicting types for
> `regex_t'
> /usr/include/regex.h:396: previous declaration of `regex_t'
> /usr/src/mapserver/../php-4.3.3/regex/regex.h:27: conflicting types for
> `regmatch_t'
> /usr/include/regex.h:427: previous declaration of `regmatch_t'
> make[1]: *** [php_mapscript.o] Error 1
> make[1]: Leaving directory `/usr/src/mapserver/mapscript/php3'
> 
> Thanks,
> 
> Jean-François Doyon

[dmorissette]

Yes, the PHP configure option --with-regex=system behaves differently whether it
is compiling as a module or as a CGI.  Actually when you compile as a module
there is absolutely no way to use the system regex.

This is a problem that I expected and for which I still don't have a nice
solution, other than modifying MapServer (the core) to build with the PHP regex
which can be quite a pain. My workaround is to configure PHP as a CGI, then
configure MapServer, and then reconfigure PHP as a module and compile it...
basically fooling the configure as you did, except that in my case it worked. ;)

FYI there's a PHP bug that talks about this but I never got any feedback from
them: http://bugs.php.net/bug.php?id=25704

[jdoyon@…]

So I've read both the bugs report and now have a much better understanding of
the issue ...

I'm curious, what about --with-regex=apache ? This does not define REGEX 1 ...

If Apache itself uses a pure system regex, then that should be ok, right ?

Of course it's not a very portable solution, as this wouldn't work for Windows
users using PHP and IIS.

But it might be a nicer interim solution ?

Or even worse, since I agree that this seems to be a PHP problem in some ways,
maybe there would need to be a requirement for Apache on windows if one uses PHP
as a module ?

[dmorissette]

I'll have to check what --with-regex=apache does.
About Windows, we definitely need to find a solution that allows us to run with
IIS, so requiring Apache isn't a solution for Windows, but I don't think we'll
have to require that anyway.

[dmorissette]

Frank Warmerdam wrote:
> Anthony Best wrote:
> 
>> 2. Replace the usage of the system regex to another implementation 
>> such as pcre, or some other standard implementation, and ensure there 
>> is no symbol conflicts.
> 
> 
> Folks,
> 
> To me, this seems like the obvious solution.  Include a small regex
> implementation as part of the MapServer source and ensure that everything
> is renamed so that there is no conflict with system or PHP regex
> implementations.  I think there has been some previous discussion from 
> which
> this was the conclusion but there just wasn't anyone motivated to implement
> the change.
> 

That's one of the options that I have had in mind for quite a while, but I find
that it's a shame to have to carry our own copy of regex just because PHP and
Apache did that and screwed our build environment.

<rant>
Unfortunately that doesn't help with other libs that PHP bundles. The next big
one is GD: PHP is also bundling its own custom GD. At least we are still able to
force PHP to build with the system GD, but most systems with PHP pre-installed
are using the bundled GD and not the system GD, so lots of people are forced to
recompile PHP to use the system GD. If we followed the same logic then should we
bundle our own copy of GD with MapServer as well? That would suck.
</rant>

[dmorissette]

Looking into this. Still trying to figure the best way to solve this :(

[dmorissette]

Fixed in 4.4.o-beta3. I've been debating whether I should bundle a modified copy
of regex or just enable building with the PHP regex and in the end I decided to
enable building MapServer with the PHP regex (see bug 520).

I'm not convinced that the fix to bug 520 will be a very robust solution in the
long run, but if we can avoid bundling our own copy of regex then it's worth a
try. In addition to code duplication, bundling our own copy of regex may have
had some license implications, so we're better avoid that as much a possible.