Ah the SDK the other guys made has those other libraries working fine without the Termux or other libs. Sorry I didn't see that. We use networking, and actually re-ported the AWS and NIO stuff as well. Will look for those dependencies.. Maybe theres a way to get the build running without them longer term by combining efforts?
Ah the SDK the other guys made has those other libraries working fine without the Termux or other libs.
Not sure what you mean, FoundationNetworking works without libcurl and its dependencies in Vlad's Android toolchain?
Will look for those dependencies
Pretty easy as it's all open source, the libcurl build script lists them. Of course, you then have to check each of their library dependencies in turn... which is why I didn't bother with it. If there had been a way to simply not build XML/Networking, I'd have done that.
a way to get the build running without them longer term by combining efforts?
Unsure what you mean, open an issue on my repo if you have some plan in mind.
| Buttaface
November 19 |
- | - |
Ah the SDK the other guys made has those other libraries working fine without the Termux or other libs.
Not sure what you mean, FoundationNetworking works without libcurl and its dependencies in Vlad's Android toolchain?
We’ve been running our big apps on Droid with their toolchain for a while now, I think it includes libcurl.
Will look for those dependencies
Pretty easy as it's all open source, the libcurl build script lists them. Of course, you then have to check each of their library dependencies in turn... which is why I didn't bother with it. If there had been a way to simply not build XML/Networking, I'd have done that.
a way to get the build running without them longer term by combining efforts?
I just mean because alot of us are going to use the full swift stuff (icu, networking, etc.) would be nice to have a set of binaries to grab.
Im going to try running with Vlad’s binaries and using your build system next- that lets us dodge the open source builds while we check into running on Droid.
Since you both do 5.3 now, we should be good.
Alright! That worked, so we have our full system building on AWS Linux2, EC2 instance with your stuff!
And running on device via Android Studio, with a java app top (we talk to the local operating system because we are like a local “Siri”).
This includes us compiling our forked NIO, AWS, crypto, and we just verified we are seeing our agent’s deposits into AWS S3 normally, so the whole stack is operational.
This also includes native use of many threads, OpenMP, and BLAS.
Importantly, this all builds with SPM, which is a massive cross platform simplication for us. Kudos to the SPM folks.
This is good, because now we have super fast local Mac builds courtesy of Vlad, and running binaries, and EC2 super fast remote builds for our customers.
We need this because we don’t want to have to deploy our more interior IP to customer development machines.
Thanks guys.
3 Likes
Have you guys gotten the static versions of the swift Libs working in android apps ? We could run a nice dead strip and also simplify our packaging if so .
1 Like
Running into some problems with the x86_64 cross compilation instructions, specifically the run steps at the end. Everything appears to have compiled properly on my Linux machine but when I get everything copied across using ADB and try to run it I get CANNOT LINK EXECUTABLE "./swift-argument-parserPackageTests.xctest": "/data/local/tmp/x86_64-unknown-linux-android/swift-android-x86_64-24-sdk/usr/lib/libicui18n.so.67" is too small to be an ELF executable: only found 18 bytes which I am assuming is a symlink issue. I will go ahead and manually delete the symlinks and rename the libraries to see if I can get the executable to run but is there an easier way to specify that symlinks should be followed?
EDIT: After replacing the symlinks with copies of the file they were pointing to the tests proceed successfully. Is there an easier way to fix this?
We’ve been running our big apps on Droid with their toolchain for a while now, I think it includes libcurl.
OK, I haven't looked at what Vlad's toolchain does about that libcurl dependency.
because alot of us are going to use the full swift stuff (icu, networking, etc.) would be nice to have a set of binaries to grab.
I wasn't sure how many people actually use those FoundationNetworking/XML libraries and tracking all their library dependencies down is a pain, so I'd have just not built them if there had been a switch to do that.
For people who really need all that, the way to do it is all outlined in the README, including building the SDK themselves (say if they want to build against another base Android API), so that's DIY for now.
we have our full system building on AWS Linux2, EC2 instance with your stuff!
Good to hear.
Have you guys gotten the static versions of the swift Libs working in android apps ?
It works with swiftc and building small executables, but when I tried it once when compiling a package with SPM for Android, there were some linker errors because of missing symbols. I didn't look into it further, could probably be made to work.
@dstoker-cricut, symlinks don't work on other partitions in Android, I think they only work in app-local directories, but wasn't sure about /data/local/tmp. I will add a note about that for now and remove all the symlinks when I script building the Android SDK for the next release, probably when 5.3.2 comes out.
Sounds good. I wrote a script to "flatten" the symlinks for now but it bloats everything since there are now three copies of each file. Looking forward to the slimmed down versions. Your work is appreciated!
Oh and hey- Android Studio doesn't like .so's with version numbers appended! I was hand editing them to get them to work there. (Vlad's are already clean.)
Oh, to be clear, we've been using vgorloffs 5.2, and also it looks like he just fixed his earlier bug where SPM builds couldn't build debug builds. Trying his 5.3 now, its useful to have Mac hosted android targeting builds as well!
1 Like
A kind of unrelated question, but, how do you are calling Swift from Java/Kotlin?
We expose swift as c functions and call normally via JNI native.
1 Like
Hmmm... did run into some problems with aarch64 and armv7. My testing I did yesterday was on x86_64 with Swift Argument Parser and after the symlink flattening it worked flawlessly. I then did the same for my package on x86_64 and it worked perfectly. However, after running the same procedure for the other two architectures I get the follow error: CANNOT LINK EXECUTABLE: "./MyPackageTests.xctest": library "libz.so.1" not found. I checked and that .so file isn't present in any of the SDK directories. Am I missing something obvious here?
I wrote a script to "flatten" the symlinks for now but it bloats everything since there are now three copies of each file.
You don't need all of them, it looks like only the lib*.so.67 ones are used by the SDK.
Android Studio doesn't like .so's with version numbers appended
@johnburkey, I've never used Android Studio, good to know.
how do you are calling Swift from Java/Kotlin?
@Gustavo, never used it, but there's also this Swift package.
library "libz.so.1" not found. I checked and that.sofile isn't present in any of the SDK directories. Am I missing something obvious here?
I just checked the libraries with readelf -d lib*.so and both libcurl and libxml2 depend on that library (or maybe your package links against that library), but as I noted above to John, I don't supply those libraries' dependencies in this SDK. Not sure why that would depend on the architecture (maybe you added it yourself for x86_64?), but you could get those dependencies yourself for now, as I linked him to above.
2 Likes
My take on Swift/Java inter-op is that we have 5-6 public functions that route stuff, and we make sure we make our stderr gets to Android stderr.
We use the @_cdecl thing to make swift emit a function thats callable from C. Then we just call it normally from the the jni native .c java people are used to for wrapping native.
@cdecl("androidBrightenPumpAudioFloat")
public func androidBrightenPumpAudioFloat( audio: UnsafePointer!, _ length: Int32,_ vad: Int32,_ doa: Int32)
{
}
Butta is right you could also do the JNI Swift auto wrapper thing- I haven't tried that. Another idea I would add is to use a form of JSON RPC or ProtoBufs over a wire protocol, for low frequency messaging. Im a fan of only adding complexity to platform connections when absolutely necessary, and things like JSON RPC and protobuf are already existing things that both languages support. We use that kind of thing when we do cross process agents, so am happy with the amount of overhead for "just did a 100ms job, here's there results" level of frequency calling.
Alright we now have 5.3 stable builds for release and debug using both Buttaface's and VGorloff's stuff! VGorloff admirably worked this weekend to solve a few more things. We had to do one work around while he is finishing up a path. Luckily SPM makes it pretty easy to add header & linker dir's to builds.
THANKS A TON GUYS
5 Likes
Hey I wanted to reopen the conversation here. We are attempting to create an Android app that uses a swift backend to perform some work. We initially tried compiling to an executable and then running that as a background process but ran into issues similar to the conversation here (https://github.com/termux/termux-app/issues/1072). So instead we decided to just create a JNI layer. We have been asked to create this using a shared library so that we don't need to distribute source code so we are trying to link using our .so file and the .so files provided by @Finagolfin. We believe we have the app set up properly to load the libraries and it is proceeding well until we hit the versioned shared library issue mentioned above (Swift for Android: Call for the Community - #50 by johnburkey). We have tried using objdump and rpl to rename and re-link the shared libraries but at the end the app is complaining about hash issues which we believe is related to editing the so files after generation. How does one use a Swift codebase as a shared library in an Android app?
Are you having issues with the swift.so's from Buttaface or your swift.so's? If your problem is with the swift.so's from Buttaface have you tried VGorloff's? Also, how are you building ? We use SPM.
The problem was with @Finagolfin's .so files. Yeah we tried using @v.gorlov's as well but the build was still claiming it needed some .so files that were only present with @Finagolfin's setup, though that is very probably due to the fact that we compiled using @Finagolfin's system. Have you been able to prove out that things work using @v.gorlov's system alone? We were planning to use Linux for our cross-compilation but are would definitely move to Mac if @v.gorlov's system is working cleanly. We are using SPM as well.
We use both SPM on linux and Mac, but use gorloff's swift .so's.