Fixes to PHP swig bindings

[mgleahy]

I've attached a patch that will allow partial functionality of the PHP swig bindings, which I had described in the gdal-dev mailing list.

Essentially, I updated the swig/php/GNUmakefile to ensure libraries are linked and that all modules were built. I also updated some of the PHP typemaps to account for a missing CSL typemap, and corrected the OGRErr typemaps to only return an error for non-zero responses. That was the first step that got the php_osr.so module working (without detailed tests that is).

I also found some function name conflicts when the gdal/ogr libraries were loaded into PHP, so I've added some %rename statements to deal with those. However, the php_gdal.so and php_ogr.so bindings still have issues. For example, CreateGeometryFromJson works with ogr, but CreateGeometryFromWkt segfaults with what appears to be a null pointer exception. php_gdal.so segfaults immediately when the module is loaded. (see the attached valgrind outputs).

Also, as I had noted in the mailing list, swig frequently inserts zend_error_noreturn into the *_wrap.cpp files, while PHP no longer provides this function. I've manually substituted zend_error so that errors can be raised within the PHP environment successfully. (I realize this is a swig-specific issue).

I've also attached a sample PHP script that demonstrates the OSR/OGR functionality, as well as raises an error with the OGR wkt geometry constructor.

I used the svn trunk to generate the attached patch, but as far as I can tell it will still work against a clean copy of 1.8.0.

[mgleahy]

Patch to compile and restore at least partial functionality to the PHP swig bindings

[mgleahy]

Sample script that does some stuff with the PHP bindings

[mgleahy]

Valgrind when running the php script from the PHP cli, when calling ogr::CreateGeometryFromWkt()

[mgleahy]

Valgrind output when running any php script, when the php_gdal.so module is loaded (segfaults on startup)

[mgleahy]

Forgot to set the version - as noted, the patch is derive from svn-trunk, but is also applicable to the current release version 1.8.0.

[mgleahy]

Revised patch adds typemap fix that allows more functionality in php_ogr.so (e.g., CreateGeometryFromWkt())

[mgleahy]

I've added an updated patch - this fixes a typemap that was returning null pointers, so now some additional functionality in the php_ogr.so module is working (e.g., the CreateGeometryFromWkt() method now works, which was producing one of the segfaults I noted earlier in this ticket).

As for the php_gdal.so module...it looks like another typemap is needed or needs to be fixed, but I can't quite discern what it should be. The specific line where the error occurs within gdal_wrap.cpp is in the SWIG_ZTS_SetPointerZval() method, specifically:

ZEND_REGISTER_RESOURCE(z, value, *(int *)(type->clientdata));

So I'm guessing something is being passed as a null value there, though I'm not sure how to determine what that is and/or what typemaps would fix it.

[mgleahy]

Sample demonstrating php_ogr.so and php_osr.so modules in action, using the v3 patch.

[mgleahy]

I've attached another sample script that illustrates at least that I'm able to open and interact with some data sets using the OGR library. I didn't think it was working, but it turns out that I can't chain methods (doing so may produce segfaults, as noted at the end of the ogrtest sample script).

I'm still stumped on how to get the php_gdal.so module to work, or at least successfully load in PHP.

[mgleahy]

Sample demonstrating php_ogr.so and php_osr.so modules in action, using the v3 patch. (fixed change for v3 patch)

[mgleahy]

Is there any interest taking a closer look at this ticket? I just tried this using the v3 patch attached to this ticket with gdal-1.8.1, and it still works as far as I was able to get on my own back earlier this year (getting all but the gdal module functional within PHP).

I'm about to attach a somewhat cleaned-up v4 of the patch (it's basically the same as v3 but I removed diffs for comments, etc). If I apply this patch to a copy of the source for gdal-1.8.1, build and install it, then cd into swig/php and run the attached compile-php script, I can successfully run the ogrtest sample (with paths adjusted as appropriate).

I don't think I'd be able to get the gdal module working without some significant guidance...but would it be worthwhile to work the patch into the code so that the osr and ogr modules can be compiled and used successfully?

[Even Rouault]

Did you have a look at Jean-François Gigand's work with his rewritten-from-scratch PHP bindings ? cf ​http://www.osgeo.org/pipermail/gdal-dev/2011-September/030081.html

At some point, I guess we'll have to decide if we just kill the existing swig php bindings or if someone stands up (you ?) to maintain them. I'm just totaly incompetent w.r.t PHP to have a technical opinion on which php bindings are better.

One point to take into account is how well PHP is supported by the SWIG project, in particular support for current PHP versions, which apparently was not obvious because of your mention of zend_error_noreturn vs zend_error.

[mgleahy]

I'm not really in any better position to offer a technical opinion - I've only been tinkering with what's already there for the PHP bindings in GDAL. I'm also not familiar with C or SWIG, so I wouldn't be a good candidate to maintain the bindings.

It is certainly interesting to see Gigand's work - I'll take a closer look at that next.

There is one concern I'd have about relying on a separately written set of bindings, which is that they can become out of sync with the functionality (as has been the case on occasion with PHP MapScript for MapServer). Is this just as likely to happen with SWIG bindings? If so, then I guess it's a moot point.

In any case, it just seems like with what I've offered in this ticket, the PHP swig bindings are almost there. But I couldn't say whether it would be more work to just get those working, or to fill-out the rest of the bindings that Gigand has implemented so far.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.