Re: [gdal-dev] Re: PHP bindings
On Sunday, February 06, 2011 14:50:34 Mike Leahy wrote: Hello List, Does anyone have an idea if there is any likelihood for a revival of php bindings for GDAL/OGR. I know if these were available, I'd be making use of them...although, I have no experience creating/maintaining SWIG libraries. So I'm curious to know what someone would need to know to get started on this, and how big of a job would it likely be? Just a quick note, that MapServer for Windows (MS4W) has always included the php_ogr extension...and if you are curious about where that project lives here is how to checkout the php_ogr code through CVS: % cvs -d :pserver:cvsa...@cvs.maptools.org:/cvs/maptools/cvsroot login Password: enter % cvs -d :pserver:cvsa...@cvs.maptools.org:/cvs/maptools/cvsroot co php_ogr Hope that helps. If you have questions about MS4W and its use of the php_ogr extension please use the MS4W mailing list (subscribe at http://lists.maptools.org/mailman/listinfo/ms4w-users) -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: PHP bindings
Mike,
Hello again,
I think I stumbled upon the part that was tripping up the methods I was
using with the php_osr.so library. Posted at http://pastebin.com/SXKKfe6v
is a patch that should work on both 1.8.0, and the trunk svn. It adds the
missing CSL typemap, and corrects the OGRErr related typemaps to ensure
that it only returns results for non-zero error responses.
I'm not sure if/when someone will act on this, but you should perhaps open a
GDAL Trac ticket and attach your patch there so it is kept in a safer place
than a pastebin that will be lost in a few days/weeks.
The patch also includes changes to the GNUmakefile in the swig/php folder
to make sure that the gdal libs are linked, and that all of the php
modules are compiles instead of just php_gdal.so (not sure if this is
fully necessary, but I was having trouble with linking before).
In addition to this, I had to substitute all instances of
'zend_error_noreturn' that swig inserts into the *_wrap.cpp files with
'zend_error'...I don't know if this is just specific to my environment, but
the best I could determine from searching online is that more recent
versions of PHP no longer define zend_error_noreturn, yet swig still uses
it. It seems that zend_error is a sufficient substitute (without this, I
would find that when the module raised errors, it would cause a segfault
instead of actually producing a descriptive error in Apache/PHP).
Perhaps something to share with the swig mailing list ?
If this patch is applied and gdal is configured/compiled with the
'--with-php' option, then when swig/php/php_osr.so is installed and loaded
into the PHP environment, the following PHP script will work as expected:
?php
include(/path/to/gdal/swig/php/osr.php);
$sr = new SpatialReference();
$sr-ImportFromProj4('+init=epsg:4326');
echo $sr-ExportToProj4();
?
This is about as far as I can get for now - looking through typemaps_php.i,
I think I see plenty of stuff that still needs fixing/updating. There are
also function name conflicts if I try to load php_gdal.so and/or
php_ogr.so. I think that's out of my league, however. Hopefully this is
enough to peak the interest of someone who has a little more familarity
with c/swig/php, and we could get a more fully-supported set of PHP
bindings.
Best regards,
Mike
On Thursday, February 24, 2011 19:45:16 Mike Leahy wrote:
Hello all,
To keep this topic somewhat alive, I might note that I can identify that
at the very least, php_osr.so works in some ways, but not how I would
expect compared with the same bindings in other languages.
I also found that at least one typemap was needed in typemaps_php.i:
/* Almost same as %typemap(out) char **options */
/* but we CSLDestroy the char** pointer at the end */
%typemap(out) char **CSL
{
/* %typemap(out) char ** - ( string ) */
char **stringarray = $1;
if ( stringarray == NULL ) {
RETVAL_NULL();
}
else {
int len = CSLCount( stringarray );
array_init($result);
for ( int i = 0; i len; ++i, ++stringarray ) {
add_next_index_string( $result, *stringarray, 1 );
}
}
CSLDestroy($1);
}
This seems to have removed the warnings about that being missing when I
compile the osr library (I'm continuing to focus just on this binding as
a simple case).
In terms of actually using php_osr.so, I can successfully import a proj4
string, and export that to WKT using the '__str__' method:
?php
$sr = new_SpatialReference();
SpatialReference_ImportFromProj4($sr,'+init=epsg:4326');
echo SpatialReference___str__($sr);
?
I would expect that the last line would be equivalent to
SpatialReference_ExportToWkt($sr);, but that isn't the case...I'm still
getting zero, which I think stems from the fact that the data type for
the ExportToWkt (and similar functions) in osr.i is of the type
'OGRErr', and this is what is getting returned in PHP instead of the
desired wkt output.
I'm guessing that there's a difference in how swig interprets these
functions when compiling in PHP versus the other languages. In osr.i, I
added an extra declaration that mimics how the __str__ function works,
but returns proj4 strings. It looks like this:
%newobject ExportToProj4Test;
char *ExportToProj4Test() {
char *buf = 0;
OSRExportToProj4( self, buf );
return buf;
}
After compiling that, the following code will successfully return a Proj4
string:
?php
$sr = new_SpatialReference();
SpatialReference_ImportFromProj4($sr,'+init=epsg:4326');
echo SpatialReference_ExportToProj4Test($sr);
?
So...with this in mind, does this suggest that PHP will essentially need
an entirely rewritten list of functions? I would hope that there's a
more effective way to go about it this, and that I'm just looking at
this with my relatively
Re: [gdal-dev] Re: PHP bindings
Even/all,
As you recommended, I've created a ticket for this
(http://trac.osgeo.org/gdal/ticket/3984). I was able to resolve the function
name conflicts (I think) that were blocking the gdal/ogr modules. After this,
I find that I can get some partial functionality out of the php_ogr.so
module...though some functions will also produce segfaults. However,
php_gdal.so causes PHP to segfault immediately on startup if the module is
loaded. I've posted some debug info in the ticket...I think it's something
to do with null pointers, which I'm guessing may need to be accounted for in
some way through the php typemaps.
Regards,
Mike
Date: Tue, 1 Mar 2011 19:59:48 +0100
From: Even Rouault even.roua...@mines-paris.org
Subject: Re: [gdal-dev] Re: PHP bindings
To: gdal-dev@lists.osgeo.org, mgle...@alumni.uwaterloo.ca
Message-ID: 201103011959.48700.even.roua...@mines-paris.org
Content-Type: Text/Plain; charset=utf-8
Mike,
Hello again,
I think I stumbled upon the part that was tripping up the methods I was
using with the php_osr.so library. Posted at
http://pastebin.com/SXKKfe6v is a patch that should work on both 1.8.0,
and the trunk svn. It adds the missing CSL typemap, and corrects the
OGRErr related typemaps to ensure that it only returns results for
non-zero error responses.
I'm not sure if/when someone will act on this, but you should perhaps open
a GDAL Trac ticket and attach your patch there so it is kept in a safer
place than a pastebin that will be lost in a few days/weeks.
The patch also includes changes to the GNUmakefile in the swig/php folder
to make sure that the gdal libs are linked, and that all of the php
modules are compiles instead of just php_gdal.so (not sure if this is
fully necessary, but I was having trouble with linking before).
In addition to this, I had to substitute all instances of
'zend_error_noreturn' that swig inserts into the *_wrap.cpp files with
'zend_error'...I don't know if this is just specific to my environment,
but the best I could determine from searching online is that more recent
versions of PHP no longer define zend_error_noreturn, yet swig still
uses it. It seems that zend_error is a sufficient substitute (without
this, I would find that when the module raised errors, it would cause a
segfault instead of actually producing a descriptive error in
Apache/PHP).
Perhaps something to share with the swig mailing list ?
If this patch is applied and gdal is configured/compiled with the
'--with-php' option, then when swig/php/php_osr.so is installed and
loaded into the PHP environment, the following PHP script will work as
expected:
?php
include(/path/to/gdal/swig/php/osr.php);
$sr = new SpatialReference();
$sr-ImportFromProj4('+init=epsg:4326');
echo $sr-ExportToProj4();
?
This is about as far as I can get for now - looking through
typemaps_php.i, I think I see plenty of stuff that still needs
fixing/updating. There are also function name conflicts if I try to
load php_gdal.so and/or php_ogr.so. I think that's out of my league,
however. Hopefully this is enough to peak the interest of someone who
has a little more familarity with c/swig/php, and we could get a more
fully-supported set of PHP bindings.
Best regards,
Mike
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: PHP bindings
Le mercredi 09 février 2011 08:47:25, Mike Leahy a écrit : Hi Tamas, Thanks for the feedback. I've tried what you suggested, regenerating the swig bindings, and setting the LD_LIBRARY_PATH...though the outcome seems to be the same. Here's my output from manually building php_gdal.so, from within the swig/php source directory: == swig -Wall -I../include -I../include/php -I../include/php/docs \ -I/sources/gdal/gdal-1.8.0 -c++ -php -o gdal_wrap.cpp ../include/gdal.i ../include/ColorTable.i:60: Warning(314): 'clone' is a PHP keyword, renamed as 'c_clone' ../include/RasterAttributeTable.i:92: Warning(314): 'clone' is a PHP keyword, renamed as 'c_clone' ../include/gdal.i:206: Warning(453): Can't apply (Pointer NONNULL). No typemaps are defined. ../include/cpl.i:228: Warning(453): Can't apply (char **CSL). No typemaps are defined. ../include/Dataset.i:474: Warning(453): Can't apply (char **CSL). No typemaps are defined. ../include/Band.i:289: Warning(453): Can't apply (IF_ERROR_RETURN_NONE). No typemaps are defined. ../include/Band.i:303: Warning(453): Can't apply (IF_ERROR_RETURN_NONE). No typemaps are defined. ../include/Operations.i:229: Warning(453): Can't apply (int nList,double *pList). No typemaps are defined. ../include/Operations.i:360: Warning(453): Can't apply (int object_list_count,GDALRasterBandShadow **poObjects). No typemaps are defined. ../include/Operations.i:474: Warning(453): Can't apply (int nList,double *pList). No typemaps are defined. g++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config \ --includes` -fpic -c gdal_wrap.cpp gcc -shared gdal_wrap.o -o php_gdal.so == At this point, I've got a php_gdal.so file, which will not load in PHP. I think for whatever reason, the module is not linking to the gdal core library. So either LD_LIBRARY_PATH has no effect, or there's something else that's being missed. Here's the output from ldd: ldd php_gdal.so linux-vdso.so.1 = (0x7fff9b985000) libc.so.6 = /lib/libc.so.6 (0x7f0a329cc000) /lib64/ld-linux-x86-64.so.2 (0x7f0a32fce000) Perhaps you must explicitely link php_gdal.so with libgdal.so ? Otherwise I do not see how PHP could figure out that it must load it... So editing the GNUmakefile to add -L../.. -lgdal might - perhaps - help. For reference, here's what you can find in the swig/java/GNUmakefile : $(JAVA_MODULES): lib%jni.$(SO_EXT): %_wrap.$(OBJ_EXT) $(LINK) $(LDFLAGS) $(CONFIG_LIBS) $ -o $@ $(LINK_EXTRAFLAGS) Disclaimer: I do not know anything about PHP, so I'm likely to say unrelevant things :-) I can successfully build /and/ load php_osr.so, Hum, strange, I don't understand why php_osr would behave differently from php_gdal or php_osr but when I create an osr object in a sample PHP script, all of the object's methods return an integer zero, instead of the expected output (e.g., importing/exporting projection text). Well, not necessarily an error. The return code from most Import/Export method is an integer/enum and 0 is the no error value (OGRERR_NONE) There are less warnings when generating the swig bindings for osr_wrap.cpp (just three, similar to the 'clone' and 'CSL' related warnings above). Also, when I run the g++ command above for osr, I see lots of warnings, such as: == osr_wrap.cpp: In function ‘char* OGRErrMessages(int)’: osr_wrap.cpp:1169: warning: deprecated conversion from string constant to ‘char*’ osr_wrap.cpp:1171: warning: deprecated conversion from string constant to ‘char*’ osr_wrap.cpp:1173: warning: deprecated conversion from string constant to ‘char*’ osr_wrap.cpp: In function ‘int zm_startup_osr(int, int)’: osr_wrap.cpp:8255: warning: deprecated conversion from string constant to ‘char*’ osr_wrap.cpp:8256: warning: deprecated conversion from string constant to ‘char*’ ... == At this point, there's not much more I can do to without some guidance from someone with a better understanding of where things could be going wrong. Is this perhaps a topic that would be better discussed with the SWIG users list? Perhaps. You need to get accustomed to how SWIG works certainly. The SWIG documentation can help a bit, but most of the learning comes from the hours of pain you will endure practicing :-) (speaking of my experience with Java and Python bindings). The 'deprecated conversion from string constant to' warnings do not sound critical. At least, I wouldn't start by fixing those ones. The priority is to implement the missing typemaps that swig warns about. You can have a look at swig/include/README.typemaps. If you have experience with one of the other bindings languages (CSharp, Java, Perl or Python), you might also take some inspiration on what they do. You will need to edit the files in swig/include/php ... Best regards, Even
Re: [gdal-dev] Re: PHP bindings
Hi Even,
It looks like adding '-L../../.libs -lgdal' did the trick to ensure that the
libraries are linked. E.g.,:
swig -Wall -I../include -I../include/php -I../include/php/docs \
-I/scratch2/gdal/gdal-1.8.0 -c++ -php -o osr_wrap.cpp ../include/osr.i
g++ -L../../.libs -lgdal -I../../port -I../../gcore -I../../alg \
-I../../ogr `php-config --includes` -fpic -c osr_wrap.cpp
gcc -L../../.libs -lgdal -shared osr_wrap.o -o php_osr.so
After doing that, ldd shows a respectable number of linked libraries,
inlcuding libgdal. I can load php_osr.so without trouble, same as before.
But php_gdal.so module now reports several conflicts when it is loaded (e.g.,
duplicate functions named 'rmdir', 'mkdir', 'unlink', etc...), so there's a
bit more to fix up in that area.
However, I'm sticking with php_osr.so as a simpler test case to start off. As
an example, I would expect the PHP code below should create a spatial
reference object for the wgs84 long/lat referenc system based on the epsg
number 4326, and export the equivalent WKT text, but I'm still getting a zero
integer returned:
php code:
$sr = new_SpatialReference();
var_dump($sr);
var_dump(SpatialReference_ImportFromProj4($sr,'+init=epsg:3587'));
var_dump(SpatialReference_ExportToWkt($sr));
outputs:
resource(3) of type (_p_OSRSpatialReferenceShadow) int(0) int(0)
In python, I can do the following:
srs = osgeo.osr.SpatialReference()
srs.ImportFromProj4('+init=epsg:3587')
print srs.ExportToWkt()
And I get the following output:
GEOGCS[GCS_WGS_1984,DATUM[D_WGS_1984,SPHEROID[WGS_1984,6378137,298.257223563]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]]
So maybe I just don't know how to interact with the spatial reference object
within the PHP environment. Any further suggestions here?
Regards,
Mike
On Wednesday, February 09, 2011 14:14:55 Even Rouault wrote:
Le mercredi 09 février 2011 08:47:25, Mike Leahy a écrit :
Hi Tamas,
Thanks for the feedback. I've tried what you suggested, regenerating the
swig bindings, and setting the LD_LIBRARY_PATH...though the outcome seems
to be the same. Here's my output from manually building php_gdal.so,
from within the swig/php source directory:
==
swig -Wall -I../include -I../include/php -I../include/php/docs \
-I/sources/gdal/gdal-1.8.0 -c++ -php -o gdal_wrap.cpp ../include/gdal.i
../include/ColorTable.i:60: Warning(314): 'clone' is a PHP keyword,
renamed as 'c_clone'
../include/RasterAttributeTable.i:92: Warning(314): 'clone' is a PHP
keyword, renamed as 'c_clone'
../include/gdal.i:206: Warning(453): Can't apply (Pointer NONNULL). No
typemaps are defined.
../include/cpl.i:228: Warning(453): Can't apply (char **CSL). No typemaps
are defined.
../include/Dataset.i:474: Warning(453): Can't apply (char **CSL). No
typemaps are defined.
../include/Band.i:289: Warning(453): Can't apply (IF_ERROR_RETURN_NONE).
No typemaps are defined.
../include/Band.i:303: Warning(453): Can't apply (IF_ERROR_RETURN_NONE).
No typemaps are defined.
../include/Operations.i:229: Warning(453): Can't apply (int nList,double
*pList). No typemaps are defined.
../include/Operations.i:360: Warning(453): Can't apply (int
object_list_count,GDALRasterBandShadow **poObjects). No typemaps are
defined. ../include/Operations.i:474: Warning(453): Can't apply (int
nList,double *pList). No typemaps are defined.
g++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config \
--includes` -fpic -c gdal_wrap.cpp
gcc -shared gdal_wrap.o -o php_gdal.so
==
At this point, I've got a php_gdal.so file, which will not load in PHP.
I think for whatever reason, the module is not linking to the gdal core
library. So either LD_LIBRARY_PATH has no effect, or there's something
else that's being missed. Here's the output from ldd:
ldd php_gdal.so
linux-vdso.so.1 = (0x7fff9b985000)
libc.so.6 = /lib/libc.so.6 (0x7f0a329cc000)
/lib64/ld-linux-x86-64.so.2 (0x7f0a32fce000)
Perhaps you must explicitely link php_gdal.so with libgdal.so ? Otherwise I
do not see how PHP could figure out that it must load it... So editing the
GNUmakefile to add -L../.. -lgdal might - perhaps - help.
For reference, here's what you can find in the swig/java/GNUmakefile :
$(JAVA_MODULES): lib%jni.$(SO_EXT): %_wrap.$(OBJ_EXT)
$(LINK) $(LDFLAGS) $(CONFIG_LIBS) $ -o $@ $(LINK_EXTRAFLAGS)
Disclaimer: I do not know anything about PHP, so I'm likely to say
unrelevant things :-)
I can successfully build /and/ load php_osr.so,
Hum, strange, I don't understand why php_osr would behave differently from
php_gdal or php_osr
but when I create an osr
object in a sample PHP script, all of the object's methods return an
integer zero, instead of the expected output (e.g., importing/exporting
projection text).
Well, not necessarily an error. The return
Re: [gdal-dev] Re: PHP bindings
Mike, Actually the PHP bindings are not maintained at all, so any improvements in this topic would be welcomed. You might also want to regenerate the bindings with SWIG since the committed version may be outdated. You should also make sure the corresponding gdal core is available load (proably by setting LD_LIBRARY_PATH). Best regards, Tamas 2011/2/8 Mike Leahy mgle...@alumni.uwaterloo.ca Hi again, I recognize this perhaps isn't a popular topic. However, I thought I'd give the PHP bingings a try with the latest 1.8.0 release. It's somewhat promising to see that enabling the php bindings in the ./configure options and compiling will succesfully produce a php_gdal.so library. After finding this, I ran make install for gdal, then copied the php_gdal.so to the PHP modules folder and configured PHP to load it. Unfortunately, I get the following output in the Apache error logs when I attempt to load the module in PHP: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/php_gdal.so' - /usr/lib/php5/20090626+lfs/php_gdal.so: undefined symbol: CPLLoggingErrorHandler in Unknown on line 0 I'm not really sure where to look next. Could it be a compatibility issue with PHP 5.3.3, or maybe for some reason the php module isn't able to access the installed gdal libraries? Any suggestions would be welcome. I'm testing this in a minimal 64-bit Ubuntu 10.11 VM. Regards, Mike On Sunday, February 06, 2011 14:50:34 Mike Leahy wrote: Hello List, Does anyone have an idea if there is any likelihood for a revival of php bindings for GDAL/OGR. I know if these were available, I'd be making use of them...although, I have no experience creating/maintaining SWIG libraries. So I'm curious to know what someone would need to know to get started on this, and how big of a job would it likely be? Regards, Mike ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: PHP bindings
Hi Tamas, Thanks for the feedback. I've tried what you suggested, regenerating the swig bindings, and setting the LD_LIBRARY_PATH...though the outcome seems to be the same. Here's my output from manually building php_gdal.so, from within the swig/php source directory: == swig -Wall -I../include -I../include/php -I../include/php/docs \ -I/sources/gdal/gdal-1.8.0 -c++ -php -o gdal_wrap.cpp ../include/gdal.i ../include/ColorTable.i:60: Warning(314): 'clone' is a PHP keyword, renamed as 'c_clone' ../include/RasterAttributeTable.i:92: Warning(314): 'clone' is a PHP keyword, renamed as 'c_clone' ../include/gdal.i:206: Warning(453): Can't apply (Pointer NONNULL). No typemaps are defined. ../include/cpl.i:228: Warning(453): Can't apply (char **CSL). No typemaps are defined. ../include/Dataset.i:474: Warning(453): Can't apply (char **CSL). No typemaps are defined. ../include/Band.i:289: Warning(453): Can't apply (IF_ERROR_RETURN_NONE). No typemaps are defined. ../include/Band.i:303: Warning(453): Can't apply (IF_ERROR_RETURN_NONE). No typemaps are defined. ../include/Operations.i:229: Warning(453): Can't apply (int nList,double *pList). No typemaps are defined. ../include/Operations.i:360: Warning(453): Can't apply (int object_list_count,GDALRasterBandShadow **poObjects). No typemaps are defined. ../include/Operations.i:474: Warning(453): Can't apply (int nList,double *pList). No typemaps are defined. g++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config \ --includes` -fpic -c gdal_wrap.cpp gcc -shared gdal_wrap.o -o php_gdal.so == At this point, I've got a php_gdal.so file, which will not load in PHP. I think for whatever reason, the module is not linking to the gdal core library. So either LD_LIBRARY_PATH has no effect, or there's something else that's being missed. Here's the output from ldd: ldd php_gdal.so linux-vdso.so.1 = (0x7fff9b985000) libc.so.6 = /lib/libc.so.6 (0x7f0a329cc000) /lib64/ld-linux-x86-64.so.2 (0x7f0a32fce000) I can successfully build /and/ load php_osr.so, but when I create an osr object in a sample PHP script, all of the object's methods return an integer zero, instead of the expected output (e.g., importing/exporting projection text). There are less warnings when generating the swig bindings for osr_wrap.cpp (just three, similar to the 'clone' and 'CSL' related warnings above). Also, when I run the g++ command above for osr, I see lots of warnings, such as: == osr_wrap.cpp: In function ‘char* OGRErrMessages(int)’: osr_wrap.cpp:1169: warning: deprecated conversion from string constant to ‘char*’ osr_wrap.cpp:1171: warning: deprecated conversion from string constant to ‘char*’ osr_wrap.cpp:1173: warning: deprecated conversion from string constant to ‘char*’ osr_wrap.cpp: In function ‘int zm_startup_osr(int, int)’: osr_wrap.cpp:8255: warning: deprecated conversion from string constant to ‘char*’ osr_wrap.cpp:8256: warning: deprecated conversion from string constant to ‘char*’ ... == At this point, there's not much more I can do to without some guidance from someone with a better understanding of where things could be going wrong. Is this perhaps a topic that would be better discussed with the SWIG users list? Best regards, Mike On Tuesday, February 08, 2011 15:44:54 Tamas Szekeres wrote: Mike, Actually the PHP bindings are not maintained at all, so any improvements in this topic would be welcomed. You might also want to regenerate the bindings with SWIG since the committed version may be outdated. You should also make sure the corresponding gdal core is available load (proably by setting LD_LIBRARY_PATH). Best regards, Tamas 2011/2/8 Mike Leahy mgle...@alumni.uwaterloo.ca Hi again, I recognize this perhaps isn't a popular topic. However, I thought I'd give the PHP bingings a try with the latest 1.8.0 release. It's somewhat promising to see that enabling the php bindings in the ./configure options and compiling will succesfully produce a php_gdal.so library. After finding this, I ran make install for gdal, then copied the php_gdal.so to the PHP modules folder and configured PHP to load it. Unfortunately, I get the following output in the Apache error logs when I attempt to load the module in PHP: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/php_gdal.so' - /usr/lib/php5/20090626+lfs/php_gdal.so: undefined symbol: CPLLoggingErrorHandler in Unknown on line 0 I'm not really sure where to look next. Could it be a compatibility issue with PHP 5.3.3, or maybe for some reason the php module isn't able to access the installed gdal libraries? Any suggestions would be welcome. I'm testing this in a minimal 64-bit Ubuntu 10.11 VM. Regards, Mike On Sunday, February
