I figured if you're happy with your current Android SDK, you could just move it to linux and then configure a similar destination.json for SPM in the linux Swift toolchain to use it. I wrote up some info on what the different cross-compilation flags mean a couple months ago and you could look at the android.json I use to cross-compile SPM itself from linux for the Termux Android app (that's specific to the standalone toolchain for Android that Termux uses, but it gives you an idea).
I get that- I just figured if I'm going to fire up an instance on EC2, etc. to ask if there's a 5.3 where someone has run swift build and seen it work targeting droid. That way we get CI of our stuff via linux and 5.3 at the same time
Do you know if anyone has built a 5.3 for Android? As you know its sort of a search for those of us who aren't actively working on the toolchains.
With SPM we already target Droid from Mac, and all the rest of our targeted platforms (Linux,Lambda,AWS Codebuild dockers), just want to move the same facilities to Linux.
Do you know if anyone has built a 5.3 for Android?
The only ones I know of are the AArch64 and ARMv7 toolchain packages for Termux that I put out and @SDGGiesbrecht's x86_64 Swift 5.3 SDK mentioned above. There might be others out there but I only use my own, never used anyone else's.
You could unpack my toolchain packages and use the Android SDK in them for cross-compilation to Android API 24 but you would also need to get dependencies like ICU, libcurl, and libxml2.
That takes some steps to setup, which is why I said you're probably best off reusing the Android SDK you're already familiar with, just transplanting it from Mac to linux. That would be easier, just tweaking your destination.json for the new paths on linux.
Whose Android SDK are you using now?
For Droid, we've been using vgorloff's, but it only built our libs release, and we had to do a bunch of surgery to get it to work. How come yours doesn't have ICU, etc. ?
Yeah, once you've done that surgery with Vlad's SDK, I figured you wouldn't want to do it again with another SDK. ;)
Mine doesn't include ICU because it's a separate Termux package, so I just have Termux install that ICU package as a dependency. You could do the same manually: get the 5-10 Termux package dependencies like libicu and libdispatch from the first link in my previous post, unpack each one with ar x package.deb; tar xf data.tar.xz, and use that to cross-compile.
I've been thinking about adding some instructions or a script that does this to the official Swift repo, for those who don't want to build an Android SDK itself, followed by simpler instructions to build an Android SDK alone, ie no hours-long compiler build, only takes 10-20 mins. The only part I'm unsure about is how to account for optional dependencies like libcurl, may leave them out.
That makes sense. Have you seen SPM working on Linux with cross compile to Droid ? Or is that more of a unicorn legend? I get that you built the cool Termux stuff- just we need to have a hosted container so we can attach to it from our Mac tools. (We built a mini IDE, and we are providing our customers with cross targeting via hosted containers)
I think the Termux stuff is super cool by the way!
Have you seen SPM working on Linux with cross compile to Droid ?
Yes, the android.json I linked you above is used to configure the linux SPM to cross-compile SPM itself for Android. Jeremy linked earlier in this thread to a github action using the linux SPM along with his Android x86_64 SDK to cross-compile the SPM tests into an Android binary then running it in an Android emulator. Take a look at his script, it does exactly the Linux->Droid cross-compile you're looking for.
Sounds like we are close to having the right bits for 5.3 then! Just need to assemble a full 5.3 SDK, sounds like. Thanks!
Hi Saleem do you have a link yet for this document?
FYI: The Swift 5.3 support preliminary complete. Needs some testing. It has less patches as we can build StdLib separately from Swift tools.
Also thinking about debug build configuration. There still enough not a flexible things inside build scripts :0
1 Like
This is amazing, very good news.
I have just put up prebuilt cross-compilation SDKs for the three most used Android architectures, along with instructions on how to use them and build the SDKs yourself if wanted. If you, @dstoker-cricut, and anyone else interested could try cross-compiling from linux (@v.gorlov reports a problem using them on a Mac) and test your Swift packages on Android, we could see how well it works. I haven't had any problems so far.
1 Like
will do
Sure I should be able to run through it tomorrow. Thanks for the hard work!
Have you seen this ?
I get everything to build and link with SPM, with a few whacks of the hammer, but on run I see this :
cannot locate symbol "_Unwind_Backtrace" referenced by "/data/app/com.brighten.BrightenAI-t4OgXkBGwOqmtO7Tgvjneg==/base.apk!/lib/arm64-v8a/libswiftCore.so"...
Was thinking it might be related to : prebuild prefab package can't be used with ndk > 21.0.6113669 · Issue #966 · google/oboe · GitHub
I found the symbol in libgcc.a- was thinking we need to link swiftCore against it or ?
No, I have not. I see that same symbol undefined in libswiftCore in the official Ubuntu release, just like this Android one, so my guess is that it's supposed to be picked up from libgcc when building your Android shared library or XCTest test runner.
The JSON files specifically include the path to libgcc, to make sure it's picked up. It sounds like you're doing something different, either with the JSON or linker used, to hit this. Try running SPM in verbose mode by adding -v, that will help track down what linker and flags are being used.
If you can't figure it out, feel free to open an issue on my SDK repo and we can discuss further there.
I forced an export of the gcc symbols into my .so and loaded it first, to make the libSwiftCore happy.
What about this one? It looks like maybe Termux includes this- its not in the libs in your build I dont think ? It shows up as needed by your libcurl.so.
NEEDED libnghttp2.so
That's one of the libcurl dependencies that I don't provide, as explained in the section on building the SDK when talking about FoundationNetworking. You could try getting those prebuilt packages from the Termux repo if you use that library, or remove them if you don't.