[gdal-dev] Current status of Android port w/ SWIG bindings? Seeking and offering help.

[Even Rouault]

Selon Jim Pendleton <jimp at ittvis.com>:

I don't know anything about the particularities of Android, but the normal
procedure to build the GDAL Java bindings is running 'make' from the swig/java
directory. The swig/java/GNUmakefile should link the *jni.so files with libgdal.
You might need potentially to tweak it if there's something specific to Android.

> Hello all,
>
> I'm new to GDAL, but I've taken on a task of extending some of our
> GDAL-oriented tools that work in the desktop environment to Android.
>
>
>
> With the help of the info on
> http://trac.osgeo.org/gdal/wiki/BuildingForAndroid I've made it as far
> as building a libgdal file for Android under both RedHat 5 and, with
> some pain, WinXP64.
>
>
>
> However, what I'm really after are the swig bindings and associated JNI
> layer for Java.
>
>
>
> Since this particular subject is listed as a "TODO" at the bottom of the
> wiki page, my assumption is that this is an active subject of
> investigation by one or more people on this list.
>
>
>
> I'm using the GDAL trunk build from approximately the beginning of July
> 2011 and I would prefer to use the recently-released version 6 NDK .
>
>
>
> Since the default GNUmakefile doesn't generate them, I've manually
> created the libgdaljni.so, libgdalconstjni.so, etc., files using the
> arm-linux-androideabi-ld in the toolchain.
>
>
>
> However when I execute System.loadLibrary on libgdaljni.so in my Android
> activity, I get unresolved reference errors.  Indeed, adding a
> -lW,--no-undefined switch shows many issues when creating the .so files
> from the swig wrapper objects, which frequently reference std:: calls
> made by the format access routines in libgdal.a.
>
>
>
> I'm not a g++/c++/makefile/compiler/linker/version guru by any means,
> but I'm willing to take a serious stab at resolving the remaining
> Android JNI issues if anyone wants to fill me in on the current status
> of this investigation and where the known technical hurdles still may
> be.
>
>
>
> Thanks,
>
> Jim Pendleton
>
>
>
>
>
>
>
>
>
>