[gdal-dev] SWIG JNI binding question with GetMetadataItem function

[Jim Pendleton]

Nikos,

 

Building for Java in a standard Linux environment is a little different
from building in the

Android environment.  We've used as a starting point these instructions:

 

http://trac.osgeo.org/gdal/wiki/BuildingForAndroid

 

Though in theory they could be buillt, the individual stand-alone apps
such as gdalinfo

must be run from a command line (I believe) which is lacking in the
Android environment, without

rooting.  Rooting is not presently an option for me for various
administrative reasons.

 

I'm actually commenting out the builds for the stand-alone applications.

 

What I'm really building in this case is the libgdaljni.so file (along
with libjdalconst.so) that can

be loaded and executed from an Android activity.  Our libgdaljni.so
contains the link results of

from libgdal.a, gdal_wrap.o and some kakadu library routines.

 

If there's an entry point within the libgdaljni.so that will perform the
equivalent functionality as

the stand-alone gdalinfo executable, I could try that.

 

Jim P.

 

________________________________

From: Nikolaos Hatzopoulos [mailto:nhatzop at gmail.com] 
Sent: Thursday, August 11, 2011 5:56 PM
To: Jim Pendleton
Cc: Even Rouault; gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] SWIG JNI binding question with GetMetadataItem
function

 

Did you follow these instructions?

http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix

this command must work:

java -classpath `pwd`/gdal.jar:`pwd`:`pwd`/build/apps gdalinfo

as the instruction are saying:
With luck you will see the gdalinfo usage message. 

and try to see a gdalinfo of a file

--Nikos Hatzopoulos

On Thu, Aug 11, 2011 at 3:21 PM, Jim Pendleton <jimp at ittvis.com> wrote:


Even,

Thanks for the suggestion, but if I've implemented your
suggestion properly, it has not solved the underlying problem.


>I'm not sure how you've compiled the gdal_warp.cpp, but if you didn't
>use the provided swig/java/GNUmakefile, there's one point you must be
>very careful that is mentionned at the bottom of that makefile :

To create a .so file from source in Android, you generally use the
ndk-build utility along with one or more Android.mk and Application.mk
files.  I execute the standard make/make install from
within the swig/java directory, then I compile and link gdal_wrap.cpp
within the context of a separate ndk-build process.

Android NDK Release 6 uses GNU Make 3.81 as its build utility.

The compiler in my case is arm-linux-androideabi-g++ (GCC) 4.4.3.

The loader is GNU ld (GNU Binutils) 2.19.


># Do not remove -fno-strict-aliasing while SWIG generates weird code
>in upcast methods
># See http://trac.osgeo.org/gdal/changeset/16006

>That would be a plausible cause for the crash, since in your
>particular case the GetMetadataItem() method is in the MajorObject
>class, so the Dataset object needs to call the SWIGDatasetUpcast()
>method...

Indeed I was lacking the -fno-strict-aliasing switch in the C++ flags in
my
Android.mk file.

However, I've added this switch to both LOCAL_CFLAGS and LOCAL_CPPFLAGS
for the libgdaljni.so build and I continue to get the error during
execution.

To add some more info to my original message, the actual error comes
from
within Java_org_gdal_gdal_gdalJNI_MajorObject_1GetMetadataItem_1_1SWIG10
in
gdal_wrap.cpp on the call to jenv->GetStringUTFChars(jarg2, 0).  First a
JNI
warning is issued, then the access violation appears to occur before
that
function can return, or at least before a debug statement I've added
after
the call can send its output to the Android LogCat output.

The error that's issued is related to jarg2 which is supposed to be a
jstring, versus the jarg1 argument you mentioned which requires the
upcast to GDALMajorObjectShadow.

I think I'll need to further debug the pointers that are being passed
down to the *GetMetadataItem*1SWIG10* function.  None of them look
outrageous at first glance.

Again, there's every reason to believe I'm missing something that's
otherwise obvious to the experts so please feel free to continue
sending ideas my way!


Jim P.
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110811/9adf7af4/attachment-0001.html