search

nakijun / spatialite-android

Automatically exported from code.google.com/p/spatialite-android
0 stars 0 forks source link

NDK Build of Geos #11

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
I have posted the issue on stack overflow. Link below.

What is the expected output? What do you see instead?
Full compile of libraries

What version of the product are you using? On what operating system?
Win7 Cygwin

Please provide any additional information below.
http://stackoverflow.com/questions/11185221/spatialite-for-android-ndk-build

Original issue reported on code.google.com by asse...@gmail.com on 25 Jun 2012 at 7:39

GoogleCodeExporter commented 9 years ago 
This is the Stack Overflow copied

I am using Win7 and Cygwin

I get the source code by cloning using "GIT for Windows". Placing it into: 
C:\temp\ECLIPSE\workspace\SA1

I download the following:

    http://download.osgeo.org/geos/geos-3.2.2.tar.bz2
    ftp://ftp.remotesensing.org/proj/proj-4.7.0.tar.gz

I place these in: C:\temp\ECLIPSE\workspace\SA1\spatialite-android-library\jni

I then start Cygwin and do the following:

$ cd c:/temp/eclipse/workspace/sa1/spatialite-android-library/jni
$ tar xvjf geos-3.2.2.tar.bz2
$ cd geos-3.2.2
$ ./configure --build=x86_64-pc-linux-gnu --host=arm-linux-eabi

Outside of Cygwin, I open in an editor: 
C:\temp\ECLIPSE\workspace\SA1\spatialite-android-library\jni\geos-3.2.2\source\h
eaders\geos\platform.h and make couple of changes so it resembles below

/* Set to 1 if you have `int64_t' type */
/* #undef HAVE_INT64_T_64 */

/* Set to 1 if `long int' is 64 bits */
/* #undef HAVE_LONG_INT_64 */

/* Set to 1 if `long long int' is 64 bits */
/* #undef HAVE_LONG_LONG_INT_64 */

/* Set to 1 if you have ieeefp.h */
/* #undef HAVE_IEEEFP_H */

/* Has finite */
#define HAVE_FINITE 1

/* Has isfinite */
/* #undef HAVE_ISFINITE */

/* Has isnan */
#define HAVE_ISNAN 1

Save and close

I then go back to Cygwin and do the following:

$ cd ..
$ tar xvzf proj-4.7.0.tar.gz
$ cd proj-4.7.0
$ ./configure --build=x86_64-pc-linux-gnu --host=arm-linux-eabi
$ cd ..
$ /cygdrive/c/android-ndk-r8/ndk-build

Along with the Compile++ lines the following compiles

StaticLibrary  : libiconv.a
StaticLibrary  : libproj.a

However while it's going through geos it comes up with the following error:

Compile++ thumb  : geos <= TaggedLineSegment.cpp
Compile++ thumb  : geos <= TaggedLinesSimplifier.cpp
Compile++ thumb  : geos <= TaggedLineString.cpp
Compile++ thumb  : geos <= TaggedLineStringSimplifier.cpp
Compile++ thumb  : geos <= TopologyPreservingSimplifier.cpp
Compile++ thumb  : geos <= Assert.cpp
Compile++ thumb  : geos <= GeometricShapeFactory.cpp
Compile++ thumb  : geos <= math.cpp
Compile++ thumb  : geos <= Profiler.cpp
Prebuilt       : libgnustl_static.a <= 
<NDK>/sources/cxx-stl/gnu-libstdc++/libs/armeabi/
StaticLibrary  : libgeos.a
make: execvp: 
/cygdrive/c/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windo
ws/bin/arm-linux-androideabi-ar: Argument list too long
make: *** 
[/cygdrive/c/temp/eclipse/workspace/sa1/spatialite-android-library/obj/local/arm
eabi/libgeos.a] Error 127
HFisher@Toshiba500 
/cygdrive/c/temp/eclipse/workspace/sa1/spatialite-android-library/jni
$

Can someone help with how I can fix this? Any help greatly appreciated!

Original comment by asse...@gmail.com on 25 Jun 2012 at 7:41

GoogleCodeExporter commented 9 years ago

Original comment by efroh...@gmail.com on 25 Jun 2012 at 5:42

GoogleCodeExporter commented 9 years ago 
This appears to be an issue with the NDK.  This error occurs when the argument 
list provided is too long.  Usually this can be fixed using a options file.  
See @<file> parameter for arm-linux-androideabi-ar.

Searching the internet it appears this issue has bee reported to Google. The 
only workaround I can offer is to use a Ubuntu VM to compile the native code.

Original comment by efroh...@gmail.com on 25 Jun 2012 at 6:05

GoogleCodeExporter commented 9 years ago 
Hi Eric,

if the binaries are available that would be fantastic.

Also just noticed that diligent...@gmail.com managed to complete the compile in 
Issue 3, would he have found the same error as above? Just wondering what he 
could have done differently?

Much Regards

Original comment by asse...@gmail.com on 26 Jun 2012 at 9:50

GoogleCodeExporter commented 9 years ago 
Have you tried adding the following to the make files?

LOCAL_SHORT_COMMANDS := true

Original comment by efroh...@gmail.com on 30 Jul 2012 at 2:06