Add 64-bit support

[Canivek]

Google Play will require 64-bit support starting August 1, 2019:

Starting August 1, 2019:

All new apps and app updates that include native code are required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play.

Source: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

[paamand]

In progress of upgrading the install script to use the r19 prebuild toolchains:
https://developer.android.com/ndk/guides/other_build_systems

[paamand]

For x86_64 and arm64-v8a I am currently getting errors with libcurl and libxml2 missing:
dlopen("/data/app/eu.paamand.usinggdal-1/lib/x86_64/libgdalalljni.so", RTLD_LAZY) failed: dlopen failed: could not load library "libgdal.so" needed by "/data/app/eu.paamand.usinggdal-1/lib/x86_64/libgdalalljni.so"; caused by could not load library "libxml2.so.2" needed by "libgdal.so"; caused by library "libxml2.so.2" not found

Trying to resolve the errors by omitting the libraries (--with-xml2=no) but wondering why I did not get the errors with the x86. Should the dependencies be included in gdal?
Any suggestions are welcome.

[paamand]

Fixed. Commit: #69731b4a59e3c21b2475273de3bb7910b8c7a06c

Notice
--with-curl=no
--with-xml2=no

[Canivek]

I tested the x86_64 and arm64-v8a compilation by removing the --with-curl=no --with-xml2=no and did not have any errors. I am able to read a GeoTiff with gdal without problem.
Compiled on a VM running Ubuntu 18.04 64-bit (same setup as the one I used previously when 64-bit wasn't added to this repository).

What was your setup to compile the x86_64 and arm64-v8a? Do you have libxml2 and libcurl installed?

[paamand]

Im running Ubuntu 18.04 as well.
Tested on a virtual device running API 21 and CPU/ABI x86_64. Fails on invoking
String versionInfo = gdal.VersionInfo();

I have curl installed but not xml2. But I would not expect the local installation to be the problem as Android would require cross compiled libs anyway.

I will try to commit the test-app.

[paamand]

An example app that crashes when i do not include --with-curl=no is now committed:

0619524

@Canivek Can you check if you can run the app with the library compiled with curl and xml2?
Also, can we somehow check if the compiled .aar is actually different from mine?:
https://drive.google.com/file/d/12QxVhl3CJiHFSy6SKMZmY5d2HLDxtbea

[Canivek]

I'm planning to test that early next week.
The aar that you included in your previous comment, it's with or without --wirth-curl=no --with-xml2=no options?
To check if the compiled aar is actually different, first I think they should have the same size, and if they don't, using AS to analyze the .aar could help to spot where the difference is.

[paamand]

The uploaded aar is with both of the flags.

…

On Sun, 12 May 2019 at 00:48, Canivek ***@***.***> wrote: I'm planning to test that early next week. The aar that you included in your previous comment, it's with or without --wirth-curl=no --with-xml2=no options? To check if the compiled aar is actually different, first I think they should have the same size, and if they don't, using AS to analyze the .aar could help to spot where the difference is. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEICZ5BCXOGIDSRWNZYS6U3PU5EM3ANCNFSM4HE35PBA> .

[Canivek]

Tested the example app with an .aar compiled without the flags --wirth-curl=no --with-xml2=no . It doesn't crash.
Used .aar: https://drive.google.com/file/d/15hKiQmL1JFGwN8vUt38iewTJUvJoecHZ/view?usp=sharing

Here a comparison done with AS APK analyzer of the .aar that I generated without the previous flags (canivek-gdal-release.aar) and the .aar that paamand generated with the flags (paamand-gdal-release_API21.aar).

As you can see, the x86 and x86_64 jni folders have a different size. Which is weird, is that the .aar with the flags --wirth-curl=no --with-xml2=no is bigger than the one without the flags.
For arm, the size is exactly the same.

Going to recompile an .aar with the flags, to see if the size difference is a result due to the flags or due to the compilation environment.

[Canivek]

Compiled an .aar with both flags. It has the same size as the resulting one when I compile it without the flags. It is working with the test app too.

The .aar compiled on my machine is different than the one that you compiled on paamand's machine. The difference is on the x86 and x86_64 arch. Any idea on what could cause that or the next investigation step that can be done?

[paamand]

Tested your .aar and indeed it doesn't crash...

1. You have a typo in one of the flags: --wirth-curl=no should be --with-curl=no. Did you compile with the typo?
2. For the compilation without the flags, did you use this config?: ./configure --host=$TRIPLE --with-libz=internal --with-cpp14 --prefix=$BUILDDIR/$ABI

Somehow it seems that the flags on your machine have no effect?
Below is an .aar without the flags:
https://drive.google.com/open?id=1CLaaNrHgFH7iXUxMseDbdR5spflXKh2U
And here is a fresh compiled with flags (which somehow differs from the previously posted. AS update maybe?):
https://drive.google.com/open?id=1QPC5hvxgHBoIATt1f8h2As2tGprmrJoJ

A comparison against your .aar shows the same difference.

• Paamand compilation with flags is exact same as Canivek compilation without flags.
• Paamand compilation without flags is a bit bigger. But only for x86_64...
• I can confirm that both work on a physical Nexus 5X device and x86 simulator, but the "without" flags fails on a x86_64 simulator. E.g. only x86_64 devices are affecte = no real-world impact...

I have no clue as to why, but forward I will not give this too much attention...

[Canivek]

1. Checked the typo problem, I did not compile with it.
2. Yes for the compilation without the flags, I used ./configure --host=$TRIPLE --with-libz=internal --with-cpp14 --prefix=$BUILDDIR/$ABI

And yes it seems like compilation with or without flags isn't changing anything on my machine.

I agree that this problem isn't a major problem, and as long as the version with flags works (which is what is commited in the repository), it is ok.