Hi, >> There is perlasm/arm-xlate.pl that enables assembly for 64-bit >> iOS, and it's being modified to cover even 32-bit iOS. > > Is that something that can/will be backported to 1.0.2- (or even 1.0.1-) > branch, once it's working?
Well, it would have to be *your* responsibility, because 1.0.2, as well as 1.0.1, are closed for new features. >> More specifically. Android has two distinct ARM targets, in sense that if >> you build JNI-enabled application, then you'd have to provide two ARM >> shared libraries, right? > > Here, you lost me. So far, I'm building only one shared library for ARM, > using the no_asm variant of OpenSSL. And so far, there weren't complaints > about unsupported devices, so what do you mean by "two distinct ARM > targets"? On Android you can build kind of "fat" apps, when same .apk contains JNI shared object modules targeting different hardware architectures, right? For example ARM, x86, MIPS. As far as I understand contemporary Android ARM platforms come in two "flavours": armhf/armv7-a and traditional armeabi. This means that along with say x86 module there is "room" for *pair* of ARM shared libraries targeting these two ABIs. Google's idea is naturally to provide better performance on former. For OpenSSL performance choice of ABI doesn't really matter (because we don't do much floating point), but it can be part of application that otherwise uses a lot of floating point and therefore is sensitive to ABI choice. This is how pair of shared libraries comes into picture. Does it mean that we better have two config lines reflecting this? That's where we need your support. To help us formulate what is sensible, what are expectations and that it would actually benefit applications. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
