[gdal-dev] Re: PHP bindings

[Even Rouault]

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 =>  (0x00007fff9b985000)
>         libc.so.6 => /lib/libc.so.6 (0x00007f0a329cc000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f0a32fce000)

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