Android Intel 32/64 bit (i.e. Android Simulator) support. #25098

vgorloff · 2019-05-28T21:32:00Z

Adds missed CMake configurations for Intel 32/64 bit (i.e. Android Simulator) support.

vgorloff · 2019-05-28T22:00:10Z

compnerd · 2019-05-28T22:31:56Z

cmake/modules/SwiftConfigureSDK.cmake

+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_NDK_TRIPLE "x86_64-linux-android")
+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_ALT_SPELLING "x86_64")
+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_PATH "${SWIFT_ANDROID_NDK_PATH}/platforms/android-${SWIFT_ANDROID_API_LEVEL}/arch-x86_64")
+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_TRIPLE "x86_64-unknown-linux-android")


I know that you are trying to match the surrounding code, but no point in the ${arch} substitution here, just spell it out.

Sorry, I didn't get .)

I am building swift with the following architectures:

-DSWIFT_SDK_ANDROID_ARCHITECTURES="armv7;aarch64;i686;x86_64"

Without changes above cmake will raise error:

CMake Error at cmake/modules/SwiftConfigureSDK.cmake:190 (message): unknown arch for android SDK: i686

Or you mean that triples x86_64-unknown-linux-android and i686-unknown-linux-android is not something expected?

Thank you!

I think he means that instead of SWIFT_SDK_ANDROID_ARCH_${arch}_TRIPLE you can write SWIFT_SDK_ANDROID_ARCH_x86_64_TRIPLE.

Personally, I prefer the ${arch} in the middle because it is easier for copy/pasting in new architectures, and also because it avoids typos in the name of the variables.

compnerd · 2019-05-28T22:34:21Z

cmake/modules/SwiftConfigureSDK.cmake

+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_NDK_PREBUILT_PATH
+          "${SWIFT_ANDROID_NDK_PATH}/toolchains/x86_64-${SWIFT_ANDROID_NDK_GCC_VERSION}/prebuilt/${_swift_android_prebuilt_build}")
+      else()
+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_NDK_PREBUILT_PATH


Can we not use ${SWIFT_SDK_ANDROID_ARCH_${arch}_ALT_SPELLING}-${SWIFT_ANDROID_NDK_GCC_VERSION} instead?

This is what I getting:

arm-4.9 NOT matching $NDK/toolchains value arm-linux-androideabi-4.9

aarch64-4.9 NOT matching $NDK/toolchains value arm-linux-androideabi-4.9

i686-4.9 NOT matching $NDK/toolchains value x86-4.9

x86_64-4.9 is matching $NDK/toolchains value x86_64-4.9

So, expression ${SWIFT_SDK_ANDROID_ARCH_${arch}_ALT_SPELLING}-${SWIFT_ANDROID_NDK_GCC_VERSION} not resolving to proper real path in $NDK/toolchains.

Details of cmake log:

>>> message(${SWIFT_SDK_ANDROID_ARCH_${arch}_ALT_SPELLING}-${SWIFT_ANDROID_NDK_GCC_VERSION}) arm-4.9 <<< >>> message(${SWIFT_SDK_ANDROID_ARCH_${arch}_ALT_SPELLING}-${SWIFT_ANDROID_NDK_GCC_VERSION}) aarch64-4.9 <<< >>> message(${SWIFT_SDK_ANDROID_ARCH_${arch}_ALT_SPELLING}-${SWIFT_ANDROID_NDK_GCC_VERSION}) i686-4.9 <<< >>> message(${SWIFT_SDK_ANDROID_ARCH_${arch}_ALT_SPELLING}-${SWIFT_ANDROID_NDK_GCC_VERSION}) x86_64-4.9 <<<

drodriguez

Looks fine to me.

I don’t know if you know, but for complete support, you might need some more pieces. Some of the parts that you might need to modify are in the following PRs that added AArch64 support: #20082, #19701, #19475, #19503

drodriguez · 2019-05-31T01:03:43Z

cmake/modules/SwiftConfigureSDK.cmake

+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_NDK_TRIPLE "x86_64-linux-android")
+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_ALT_SPELLING "x86_64")
+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_PATH "${SWIFT_ANDROID_NDK_PATH}/platforms/android-${SWIFT_ANDROID_API_LEVEL}/arch-x86_64")
+        set(SWIFT_SDK_ANDROID_ARCH_${arch}_TRIPLE "x86_64-unknown-linux-android")


I think he means that instead of SWIFT_SDK_ANDROID_ARCH_${arch}_TRIPLE you can write SWIFT_SDK_ANDROID_ARCH_x86_64_TRIPLE.

Personally, I prefer the ${arch} in the middle because it is easier for copy/pasting in new architectures, and also because it avoids typos in the name of the variables.

vgorloff · 2019-05-31T18:44:06Z

@swift-ci Please test

drodriguez · 2019-05-31T21:44:19Z

@swift-ci please test

finagolfin · 2019-06-03T16:19:39Z

Were you able to run the Swift validation testsuite in the Intel simulator, as currently done for ARM on an external device? I'm guessing you will run into issues, as Android's x86/x64 support is buggy, likely because no Android devices ship with Intel chips anymore.

vgorloff · 2019-06-03T16:28:26Z

Were you able to run the Swift validation testsuite in the Intel simulator, as currently done for ARM on an external device? I'm guessing you will run into issues, as Android's x86/x64 support is buggy, likely because no Android devices ship with Intel chips anymore.

This PR is only first of approximately 10 PRs targeted Android support.
Android's x86/x64 needed in order to have ability to develop on Android Virtual Devices.

In this Repo (https://github.com/vgorloff/swift-everywhere-samples) you can find few examples which shows that all 4 architectures (Android 32/64 bit ARM/Intel) are working fine. So, Intel Android 32/64 is not something deprecated, it is just about Simulators.

Thanks!

finagolfin · 2019-06-03T17:04:37Z

This PR is only first of approximately 10 PRs targeted Android support.

Great, would be good to get those in, as I'm guessing they affect ARM also?

Android's x86/x64 needed in order to have ability to develop on Android Virtual Devices.

Sure, would be good to have, just pointing out native testing on ARM is better.

In this Repo (https://github.com/vgorloff/swift-everywhere-samples) you can find few examples which shows that all 4 architectures (Android 32/64 bit ARM/Intel) are working fine.

Those simple "hello world" apps don't really show much, but it's good you got those basics working.

So, Intel Android 32/64 is not something deprecated, it is just about Simulators.

Maybe not deprecated, but IME somewhat buggy. Anyway, you didn't answer the question: this project supports running the testsuite remotely on Android through adb but only configures those tests for ARM, did you do the same and run the testsuite on Intel chips, ie the Android Simulator? Those results will give us an idea of how far along the port is, just as my reported results when running the compiler and testsuite natively on Android showed in #23208.

drodriguez · 2019-06-03T17:44:47Z

@vgorloff no rush or anything, but if you are intending to open more PRs with changes related to this, please mention me so I can have a look at them. While work on x86 is not interesting for devices, maybe this can be used to run simulators in the CI machines which performs tests that cannot be check in ARM (it doesn't cover all the bases, but it covers more ground).

vgorloff · 2019-06-03T18:01:41Z

I am have a chicken egg problem .)

Officially Cross Compile for Android on Mac is not supported and requires a several patches for Swift, Dispatch and Foundation. Currently I am not performing any tests except "hello-world" on my Android device and Simulators. Running "serious" tests means using Official Build scripts (written on Python) on official CI server. I can port Ruby scripts I made in alternative Toolchain (https://github.com/vgorloff/swift-everywhere-toolchain) to Python later. Doing one big PR with all fixes - not realistic at the moment :0

Later there will be PRs addressed FileManager, Float80, Cmake configurations for Dispatch and Foundation, etc.

drodriguez · 2019-06-03T18:16:56Z

Yes, I try from time to time to cross-compile Android on Mac, and the special usage of CMake and the mix that happens between the build host and the target host is a PitA. I don’t think there's a good way to fix all those cross-compiling problems right now. The best way we know for cross-compiling Android is still Linux or Windows.

vgorloff · 2019-06-03T18:32:20Z

The thing, that I am created that alternative Swift build toolchain and now porting patches into official one for the exact purpose – CrossCompile on Mac. Launching Vagrant box with Linux is not a big deal. But final goal is to develop everything on mac and compile/package for mac/iOS/Android and later Linux/Windows/Pi.

In fact we can even now copy prebuilt Android libs into /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/android. And Xcode-supplied swift compiler will successfully compile and link ELF ARM exe/lib. Of cause if proper tripple provided.

finagolfin · 2019-06-03T18:53:16Z

Nice, I see you ran into similar issues as I did. My advice would be to keep the two efforts separate: get the Android x64 tests built on Linux and run them in the Android simulator and separately get Android ARM cross-compilation working with the Python build-script on the Mac. Once both are working separately, it should be easy to combine them.

vgorloff · 2019-06-04T20:17:17Z

Hi,

Should we run @swift-ci please test and merge in order to merge this PR or it can be merged manually?

Thank you!

Android Intel 32/64 bit (i.e. Android Simulator) support.

096f7f3

vgorloff changed the base branch from master to swift-5.1-branch May 28, 2019 21:59

vgorloff changed the base branch from swift-5.1-branch to master May 28, 2019 21:59

compnerd reviewed May 28, 2019

View reviewed changes

drodriguez approved these changes May 31, 2019

View reviewed changes

drodriguez merged commit 9498b14 into swiftlang:master Jun 4, 2019

vgorloff deleted the macos-to-android-crosscompile branch June 13, 2019 21:52

Android Intel 32/64 bit (i.e. Android Simulator) support. #25098

Android Intel 32/64 bit (i.e. Android Simulator) support. #25098

Uh oh!

Conversation

vgorloff commented May 28, 2019

Uh oh!

vgorloff commented May 28, 2019

Uh oh!

compnerd May 28, 2019

Choose a reason for hiding this comment

Uh oh!

vgorloff May 29, 2019

Choose a reason for hiding this comment

Uh oh!

drodriguez May 31, 2019

Choose a reason for hiding this comment

Uh oh!

compnerd May 28, 2019

Choose a reason for hiding this comment

Uh oh!

vgorloff May 29, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

drodriguez left a comment

Choose a reason for hiding this comment

Uh oh!

drodriguez May 31, 2019

Choose a reason for hiding this comment

Uh oh!

vgorloff commented May 31, 2019

Uh oh!

drodriguez commented May 31, 2019

Uh oh!

finagolfin commented Jun 3, 2019

Uh oh!

vgorloff commented Jun 3, 2019

Uh oh!

finagolfin commented Jun 3, 2019

Uh oh!

drodriguez commented Jun 3, 2019

Uh oh!

vgorloff commented Jun 3, 2019

Uh oh!

drodriguez commented Jun 3, 2019

Uh oh!

vgorloff commented Jun 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

finagolfin commented Jun 3, 2019

Uh oh!

vgorloff commented Jun 4, 2019

Uh oh!

Uh oh!

vgorloff May 29, 2019 •

edited

Loading

vgorloff commented Jun 3, 2019 •

edited

Loading