At the moment, we are trying to integrate the latest libspotify release 12.1.51 eabi-armv7.
This library has been developed for a soft-float kernel running on ARM7.
We are using a more recent hard-float kernel on our platform, requiring a hard-float version of the libspotify for ARMv7.
The hard-float release offered by spotify is for ARM6, so we can’t use it.
Any idea on how to get this?
ARMv6HF libraries should work just out of the box on ARMv7HF systems.
It will not take use of some instructions that's available on the v7 CPU but apart from that it should work just fine.
Related
We have some servers with ARM CPU and will test some SW applications. With Ubuntu system, there is no big problem because the kernel and the SW are quite up-to-date. But with CentOS system, some tools and libs are quite old on ARM. For example, the GCC compiler is still 4.8.5 and some features couldn't be supported.
On X86_64, this is not a problem, because there are SCL and other sources with stable packages.
On ARM, now I find to choices, one is from RH and the other is from Linaro.
https://releases.linaro.org/components/toolchain/binaries/latest/
The Linaro project provide some source of GCC5, 6 and 7. We could build and run on the system. Ubuntu ARM version is using the GCC from Linaro right now. But on the release notes, it just mentions Ubuntu but no CentOS support. (Even this could be done on CentOS)
https://buildlogs.centos.org/centos/7/sclo/aarch64/rh/
The RH also provide the GCC for aarch64 as on the X86_64 computer/server. But now it is still in the test repository but not the official update sources. And only GCC6 and 7 are provided.
So any suggestion? Should I use the test version from centos.org or the source code from Linaro.
Many thanks in advance
Depending on the ARM CPU Servers are you targetting, the vendor may also provide you with the OS and packages/repo which is recommended to be used.
Linaro might be a better pick than the test repo (expected to be more stable) in the case that you are doing some functional/performance testing of SW applications. Even though centos7.4 is not stated as officially supported platforms, its worth a try. Its likely that the Linaro GCC toolchain will just work on the OS of your choice.
You may also download the latest GCC from the public mirrors and try, say one of the GCC 7 releases (At the moment, the latest is gcc 7.3.0 https://gcc.gnu.org/gcc-7/). Aarch64/Aarch32 are supported targets.
Whatever you chose, ARM CPU server ecosystem is actively evolving as these chips are just hitting the market. You might want to check which of the above (Linaro/GCC/RH) is being actively contributed to in the area of the target platform of your choice.
I'm developing an app for API level 15+ that has some jni code and i'm wondering if there are devices with armeabi ABI (ARMv5) and API level 15+
Can i include only armeabi-v7a and x86 libraries and skip the old armeabi?
Android itself doesn't support ARM versions below ARMv7 from Android 4.4 (API level 19). Since Android 4.0 (API level 15), it doesn't support ARMv5/ARMv6 by default but can be modified to build for those platforms (see https://groups.google.com/d/msg/android-building/Q_gU1zb6DLc/Bq5QryioQ_kJ), and there are custom builds that run on ARMv6. I'm not entirely sure if there are any official, certified compatible devices that run such a combination (Android 4.0-4.3) though - there should at least not be any such certified devices running Android 4.4, since the compatibility definition document strictly requires ARMv7 from that version.
So in practice you should be pretty safe to skip it, but you might exclude some fringe third party ROMs by doing that.
See https://stackoverflow.com/a/28926267/3115956 for a similar answer to a similar question.
Can i include only armeabi-v7a and x86 libraries and skip the old armeabi?
No, iff app is to be used on old cpu based architecture devices.
And Yes, if we are sure that no customer have older than ARM7 cpu based architecture device.
In our case we purchased the Chilkat licence for one year and they happily supported with ARMEABI .SO files. Hence it is upto the use case. It is affordable for and organisation.
Also wants to share the contact point for Chilkat if anyone wants to contact them for help. Email them at -> support#chilkatsoft.com
Thank you and Happy coding!!!
I was trying to follow the the installation tutorial of the Native Client SDK found here. However, my Samsung Chromebook (in developer mode) does not want to run ./naclsdk (chmod +x done), but instead returns the following:
32-bit runtime environment was not found on this
system. Specifically the 32-bit dynamic loader which is needed by the NaCl
compilers was not found ('/lib/ld-linux.so.2'). On modern debian/ubuntu
systems this is included in the 'libc6:i386' package.
On here they write that the PNaCl should run on ARM computers, however, on some other forums I read that wasn't the case. I've tried enabling two flags, as described on a site which I can't post due to a lack of reputation, but it looks like that'll only change things when using PNaCl, not during the installation of the SDK.
Is it possible to install that SDK on my Chromebook and, if so, how?
There's a bit of confusion: when the documentation says "PNaCl and NaCl work on ARM", it means the part that runs inside of Chrome which users would use. The SDK is currently only built for x86-64 Windows/Linux/OSX, and not for ARM. The main reason is that it's never been requested, probably because ARM machines are quite slow compared to usual development machines.
That being said, I don't think it's silly to use ARM as a development machine, and I've built my own PNaCl toolchain for ARM in the past. There are build instructions for the toolchain. I haven't built it recently, and it may have bitrotted a bit so if you run into issues I suggest emailing the team or better yet sending a patch! I expect any issue to be fairly minor, especially if you only want to use pnacl-clang or nacl-clang (as opposed to the GCC toolchain).
I've a problem with a library developed in Visual C++ with Cuda.
I want to use my dll on different computers, all with NVIDIA drivers, but it depends
by CUDART32_42_9.DLL and CUBLAS32_43_9.DLL; so, depending on 32_42_9, it doesn't work with any different cuda version: neither inferiror (that is reasonable) nor superior (that is my problem).
Have you got any suggestion about how to solve the problem? Do I have to deploy my library with CUDART32_42_9.DLL and CUBLAS32_43_9.DL attached?
Thank you!
It is the responsibility of the application developer to redistribute the necessary CUDA libraries with the application. The EULA.txt document in the CUDA Toolkit doc directory has a section Attachment A that defines Redistributable Software. Redistributable software includes but is not limited to cudart* and cublas*. See EULA.txt for more details.
The end user will need to download a compliant version of the NVIDIA graphics driver for their platform.
Here is the situation: I've built a native library for re-distribution in other apps. Because we're using ARMv7 NEON, we ship two versions of the library: One for most devices and a "fallback" limited capability version for ARMv5/ARMv6. So far so good and this has worked well.
However, for some reason a newly created app running on a Nexus S with Android 4.0.3 is picking up the wrong (armeabi rather than armeabi-v7a) version of the library.
If we dig into the device filesystem, we find that /data/app/my_app.apk contains the correct versions of the library. However, when Android extracts it to /data/data/my_app, we find that /data/data/my_app/lib/my_lib.so is the armeabi version. But, strangely, /data/data/my_other_app/lib/my_lib.so is the correct armeabi-v7a version.
So the questions are:
1) WTF??
2) How does Android decide which eabi to extract from the APK?
Yes, this is known bug in ICS - it chooses wrong library.
Read about it here:
http://www.moodstocks.com/2012/03/20/ice-cream-sandwich-why-native-code-support-sucks/
https://groups.google.com/d/msg/android-ndk/N8FLjvM81pg/2rYeClQZcckJ