meta-android-ndk: initial version that could build some simple utility

meta-android-ndk: initial version that could build some simple utility

[Randy Li]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

Hello All:

It now could compile the libpng and its unit test, I could run it on an Android 11 board. But there are still many problems waiting for solving.

The building above would fail the OE package QA test. There is not a library linker file in Android, all the library files won't have a version suffix, I am still finding a method to let this checking being disable for the Android target.
You could try it here
https://github.com/hizukiayaka/meta-android-ndk

I am not sure I understand all the variables that were not recorded from the reference manuals. So I didn't package the Android NDK toolchain into an OE toolchain and I skip the canadian toolchain as I don't think an external toolchain would need it. I left many things hardcode in the tcmode file as I have no idea how to make the meta-clang not try to build me a new clang cross compiler. I am not familiar with LLVM as well, I don't much idea on which library comes from where and Google also lacks documents for it.

Let me list those things I am not sure whether I did it right here, please help me solve them.
I have to export some variables globally, like HOST_SYS, TARGET_PREFIX, and TARGET_OS. I thought the meta-external-clang would help me overwrite them but it doesn't.
How would I deal with the package for development? As I said, there is not a version suffix in Android's library name, only something likes company name would be used for export native libraries to general application. Those development packages would have the headers files and some object files, could I just remove that QA checking ?
Both HOST_PREFIX and TARGET_PREFIX objdump would be used in some classes but android only provides a version. Also, there is an llvm-objcopy(and llvm-objdump), I didn't found meta-clang would use it;
Should I package the Android NDK toolchain into clang-cross-${TARGET_ARCH} ? I could certainly skip the candian part right?
How to deal with those recipes depending on a kernel module? Although I could let the OE build a kernel image it just would not be used anywhere, could I just make a dummy target?

Later we could move to the final packing, we should not ship those public libraries from the Android NDK and get rid of all the daemon service files. But I could just copy what I need from the staging directory so far, we could think of this later.


ayaka

[-- Attachment #2: Type: text/html, Size: 6253 bytes --]