PHP/Mapscript regex problem -- Any volunteers?

[Bill Binko]

On Fri, 13 May 2005, Daniel Morissette wrote:
> It's not that the non-php regex library is more forgiving. The key is
> that you need to make sure that both your PHP and the
> MapServer/MapScript code are compiled with the same regex.

Right: understood that.  The problem is that I just went through 3 days of
hell upgrading Mandrake 10.1 so that I would have a working src RPM (their
fault -- not Mapservers).  Now I _have_ compiled against the same regex as
the PHP libraries.  And when I use the command-line/CGI tools (like
shp2img and mapserv), I get a segfault.

> The reason is
> that the PHP regex and the system regex use the same function names and
> regex_t data structure, but they are defined differently and with a
> different size. When you compile PHP and MapScript with different regex
> libs, then at runtime you end up with duplicate sets of regex symbol
> names, and depending on where you are in the code, the wrong symbols
> could sometimes be used randomly and lead to the crashes you've experienced.
>

Just to make sure I understand this, does sizeof(regex_t) change?  Do the
parameters differ?  I thought that PHP shipped with a POSIX compliant
implementation of regex.  Perhaps I'm wrong, and there are differences.
If they have exactly the same interface, there are some solutions we could
try.

> Well, I'd like an easy fix for this but I don't think there's one.

I hope you're wrong :)

> The reason why we require the source if you are using the PHP built-in
> regex is that at the moment, an installed PHP package exposes the
> regex/*.h files, but doesn't expose the regex/*.o files We could compile
> php_mapscript.so from the .h files and the regex symbols would be
> resolved at runtime because they are part of the php executable, but
> that wouldn't work for the mapserv and other command-line executables,
> they'll require the regex/*.o files to link with. The only alternative
> then would be to do separate builds everytime for php_mapscript.so and
> for the mapserver core binaries, quite a clunky solution.

Actually, couldn't we just link them differently?  Link mapserv, et al
against the system regex, and leave the php_mapscript.so unlinked.  If the
definitions are identical, the .so will find the symbols when it is loaded
into the php executable.

It shouldn't require a rebuild: just that the mapserv executable needs to
link to the dynamic, not static libregex.

> The best solution in my opinion is that PHP should be designed to use
> the system regex...

That certainly would be ideal....

> that's what system libraries are for after all: all
> packages on a system that require a given library should use the system
> copy so that they can easily interact.

That's a broad brush -- the PHP team may have found several key platforms
have horrific performance/major bugs in their regex and provided a POSIX
compliant replacement.  I have no doubt that there are easier ways to
integrate with this (there are simply too many PHP extensions that use
regex) -- we just need to figure out how.

>
> Well, one possible solution could be for us to also package our own
> built-in regex after renaming the regex_t data structure and all the
> functions, but I think that would be a move backwards.

I would agree

>
> So if you or someone else can get a hold of someone in the PHP dev't
> team and get an explanation of why they force the use of the built-in
> regex and what they propose as a solution to this mess, then we may be
> on the way to find a solution.
>

I'll be happy to give that a shot.

>
> Note that the above is based on information I had the last time I looked
> into this, maybe a year ago. It's possible that something changed in PHP
> since then (maybe in PHP 5)? to make it easier to integrate PHP with
> large packages such as MapServer, if that's the case then I'd like to be
> pointed in the right direction.
>

I'll let you know.

>
> P.S. An alternative to doing your own builds would be to use the
> precompiled FGS Linux packages: http://maptools.org/fgs/ ... you'd be
> running with PHP MapScript in a few minutes.
>

(Erg.  Please take this the right way - I haven't been here long enough
to lecture...)

That simply isn't a solution.  Not just for me: for the project.  We need
our users to be able to access the source, and build it effectively.  If
not, we lose many of the benefits of Open Source.  I know I'm not the only
one who's picked up Mapserver, found it didn't do something he needed, and
dug into the code to add it.

Bill