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 => (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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
