Add arm64 As Supported ABI #1956
Comments
|
Added Brads-MacBook-Pro:mapbox-gl-android brad$ make android-lib-arm64-v8a
git submodule update --init src/mbgl/util/geojsonvt
deps/run_gyp android/mapboxgl-app.gyp -Dhost=android -Iconfig/android-arm64-v8a.gypi -Dheadless_lib=none -Dplatform_lib=android -Dasset_lib=zip -Dhttp_lib=curl -Dcache_lib=sqlite --depth=. -Goutput_dir=. --generator-output=./build/android-arm64-v8a -f make-android
gyp: Undefined variable openssl_ldflags in android/mapboxgl-app.gyp
make: *** [Makefile/android-arm64-v8a] Error 1 |
|
Discovered that the android-arm64-v8a.gypi android-arm-v7.gypi |
|
Looking at differences between two files ^^, it appears that the android option in the |
|
I will take a look. I think arm64 used to build OK. |
|
The issue is that the make android-lib-arm-v7 make android-lib-arm64-v8a |
|
@ljbade Interesting. Yeah, I just swapped out the default value for ANDROID_ABI of Why this issue is important:
|
|
Just noticed on Travis that in the build matrix, irrespective of what @kkaefer Does the build system still listen to |
|
@bleege Did some tests. On current master Can you try that command and then see if you can roll a ARM v8 snapshot for @incanus to test on his 64-bit device? I am currently installing an ARM v8 virtual device to give it a quick test too. Also working on fixing the Travis build to correctly build each ABI. |
|
@bleege after |
|
No longer a problem after build system was refactored. |
|
be sure to let me know if there's any debug info I can capture that will help nail this down |
|
Let me fire up the simulator |
|
Hmm there is no 64bit simulator! |
|
What about this 64 bit emulator from Google? |
LOL |
|
Currently poking around here in Nexus 9 device vs. Nexus 4 emulator with Capturing setup from chat with @bleege:
|
|
Hmm my findings are that it crashes in
|
|
Ok, this is going to cause some heads to explode, but I just found the following link on Android's JNI Tips Web site entitled "64-bit Considerations". It reads:
So... this means (to me) that we either go back, convert Thoughts? |
|
Please see my comments below to see why creating ARM-V8 specific .so should be possible. 1.) Android NDK includes a sample opengl application. This application creates an ARM V8 specific .so. This uses Android.mk and the built in macro to create the shared library. If we can we get this application to work with clang++ on ARM64, then we should be able to get mapbox-gl-native working as well. 2.) If you have a rooted 64 bit Android device, you can also check if Google Map includes an ARM-V8 specific .so or not. Or you can just download one from here and verify that it includes an ARM V8 specific .so. |
|
1.) There is absolutely no need to convert int to long in native code base as long as we are using jlong in native code (jni.cpp). long is 4 byte on 32-bit platforms and 8 byte in 64 bit platforms. This is why this data type is used to store pointers in code that is compiled for both 32-bit and 64-bit architectures. This is pretty widely used. This is not java or android specific. Even mapbox-gl-native code works find on both x86 (32-bit) and x86_64 (64-bit platforms). 2.) Android NDK recommends using Android.mk and built in macros to add architecture specific compile flags. Since we are not using this, its possible that we are not passing the right compiler flags when compiling native code. Trying to get the sample application working with clang++ would help us identify these flags. Simply eye-balling the build.log for arm-v8 shows that something is amiss. Here is one such example. When building for armeabi, we add flag "-march=armv5te". |
A little out of my depth here, but I will give it a whirl. |
|
@mb12 This is all really good to know and I think we could work towards that in time. @incanus is correct about what I'm thinking here.... this is something that we'd have to audit and has a high potential for being rabbit hole time wise (happy to be wrong though!). This plus with what Google is explicitly saying:
Again, I'm happy to be wrong about all this if it can be done. I'm just trying to be practical as we have 32bit working on 64bit devices, which is (my interpretation of) what Google suggests. |
Reading around, I am feeling better about this route for |
|
We do currently use @mb12 If you look in the NDK scripts you will see ARM64 does not use I vote for 32bit only for We should document this ^ somewhere as it will only show up when testing on a 64bit device. |
We were getting segmentation faults and illegal instructions. My take is support for aarch64 + C++14 symbols is fresh. I didn't find anyone else reporting similar issues so I created one on AOP. AOP issue: https://code.google.com/p/android/issues/detail?id=204151 Mapbox GL Native issues: mapbox/mapbox-gl-native#1956 mapbox/mapbox-gl-native#3128
We were getting segmentation faults and illegal instructions. My take is support for aarch64 + C++14 symbols is fresh. I didn't find anyone else reporting similar issues so I created one on AOP. AOP issue: https://code.google.com/p/android/issues/detail?id=204151 Mapbox GL Native issues: mapbox/mapbox-gl-native#1956 mapbox/mapbox-gl-native#3128
Nexus 9 devices are arm64 based so Android GL needs to provide a arm64 based
libmapboxgl.sobinding. Update build process to support this ABI.https://developer.android.com/ndk/guides/abis.html
/cc @incanus @ljbade
The text was updated successfully, but these errors were encountered: