Conversation

I cannot vouch for our current system as I did not design it. I maintained the prior build system, which had Gradle invoking CMake. The pure-CMake setup is new. It's possible Gradle read AndroidManifest.xml, saw the minSdkVersion there, and translated that into a CMake define...
1
If this is the case, then this simply means that our new non-Gradle setup would need to have the human specify those AndroidManifest.xml-related defines by hand. But I'm not clear who they should be defined to (to CMake? To toolchain.cmake? To clang?)
1
You definitely need -D__ANDROID_API__=21 in CPPFLAGS to match your minSdkVersion 21. It's broken overall, but you only happen to be seeing it when _FORTIFY_SOURCE is used because _FORTIFY_SOURCE will automatically use the new symbols introduced for newly fortified functions.
1
1
It *sounds* like it might be optimizing some files (where it would pass -D_FORTIFY_SOURCE=2 by default) and not others. The _FORTIFY_SOURCE thing is just what let you know it's broken though. Real issue is not having minSdkVersion set for C and C++ so it's defaulting to 30+.
1
You probably just need to set --target=aarch64-none-linux-android21 rather than --target=aarch64-none-linux-android26. It's the minSdkVersion that needs to be set at compile time for __ANDROID_API__ rather than the targetSdkVersion which is checked at runtime.
1
So, I believe what is controlling this is -D ANDROID_NATIVE_API_LEVEL=26 , which is being passed to CMake (not clang) and is most likely being interpreted by the CMake toolchain file (script). Problem: If I set this to 21, I get this legitimate-looking error:
Image
1
Show replies