For clarity:

• The part of this that fixes [Bug]: clang cannot compile for api levels other than default #23401 is purely the fixes for on-device building
• The removal of the custom definition of __ANDROID_API__ is actually not required for solving that issue and it's just a follow-up change after fix(main/libllvm): Implement all executables named after triplets with scripts #25627
  • Benefit of that part: if applied, it would hypothetically allow developers of esoteric on-device building projects, to manually set --target=aarch64-linux-android (without API level specified) and experience "vanilla" behavior from that codepath (not setting __ANDROID_API__, like what the cross-compiler does), if they want such a thing.

The binary reports itself as for Android 26, but actually it use the crtbegin_dynamic.o that is shipped by NDK and compiled as target 24.

I really don't think this is the right way to resolve issue 23401.

CC: @truboxl

The binary reports itself as for Android 26, but actually it use the crtbegin_dynamic.o that is shipped by NDK and compiled as target 24.

Could you explain how you can tell that the incorrect crtbegin_dynamic.o actually is used in the binary?

what is the SHA256 of the correct crtbegin_dynamic.o for, for example, API level 26 64-bit x86, in your opinion? I believe it is 8fd4fa4102ca25fdf5f640753a3bcb9967606e822ef9333363bfc3d986157918, but is this incorrect?

There is no other crtbegin_dynamic.o in Termux, unless you copy it yourself rather than using apt install ndk-sysroot.

crtbegin_dynamic.o in $PREFIX/lib is targeting API 24, see

There is no other crtbegin_dynamic.o in Termux, unless...

I think I understand the concern you are explaining here. Actually, the solution I intend to create to issue 23401 does involve commands that are not apt install ndk-sysroot - you are correct in assuming that.

Actually, the intended use of this PR in the context of serving as part of the solution to issue 23401 revolves around the series of commands I sent to the original poster of the issue in the issue thread.

I referred to this PR as the "solution" because it is a required dependency of the commands which I sent.

Please read these (and expand the collapsed markdown block) to understand further context:

• [Bug]: clang cannot compile for api levels other than default #23401 (comment)

@licy183 I am sorry for not getting to the point very well. I didn't want to say something that sounds like an accusation of your code having a problem, which is why I did not outright say this anywhere at first, but I realize that beating around the bush can just cause unnecessary confusion:

I primarily requested your review on this because I am editing this code you added in 09d6130, which appears to not work if TERMUX_ON_DEVICE_BUILD=true, because of the folders being in the wrong places.

Please read these (and expand the collapsed markdown block) to understand further context

Actually I've read your comment before I made my last one.

I primarily requested your review on this because I am editing this code you added in 09d6130, which appears to not work if TERMUX_ON_DEVICE_BUILD=true, because of the folders being in the wrong places.

I didn't actually build ndk-sysroot on device in that commit, I just assumed that it would work.

Anyway, I feel that this fix is ​​a bit strange and cannot be considered to solve 23401. The only way to solve 23401 seems to be to package all the prebuilt libraries of NDK, which does not seem to be necessary.

Anyway, I feel that this fix is ​​a bit strange and cannot be considered to solve 23401. The only way to solve 23401 seems to be to package all the prebuilt libraries of NDK, which does not seem to be necessary.

I have a different opinion from you about this, because, for example, I do not think it would be good to package all of the binaries for all API levels at once, because on the majority of devices and situations they would not be useful.

In my personal philosophical opinion this does fix issue 23401 because, I argue, that the correct way to target alternative API level in Termux on a case-by-case basis for personal projects, which is exactly what OP was doing, should consist of:

step 1. build and install ndk-sysroot on-device with custom TERMUX_PKG_API_LEVEL

step 2. manually apply the desired API level to clang using the --target=aarch64-linux-android$API_LEVEL argument, with $API_LEVEL manually set to the desired API level

^ and those are exactly the things that are covered and fully explained in my response on the issue.

I don't believe that packaging and hosting multiple API levels of packages in the same Termux mirror set makes sense, because normally the API levels of the packages are uniform within a mirror set (example android21 in the android 5 mirror set, android24 in the f-droid termux mirror set, android29 in the google play termux mirror set) therefore I don't agree that putting all API level binaries in some packages in the same mirror set would be a good solution to issue 23401, and therefore my proposed solution is, in my opinion, the most idiomatic way to support that need of users in Termux.

I would be interested to see the opinions of others about this also,

and whether others think that this PR could be considered as the solution to issue 23401, or not.

Also, while it is not the only factor, IMO one of the most important factors is whether the OP of the issue believes their issue is solved yet or not, since they are the one trying to target a different API level.

Therefore, if they respond I think it will be important to consider what they say, and whether or not they still have other problems and errors happening when they try this possible solution.

When I think about it a lot, I think that the argument can be made that multiple API levels of ndk-sysroot should be provided in the same mirror set if there is specifically a situation where developers (clang package users) who are targeting different API levels, need to frequently, or even multiple times within the same build script or test script on the same device, switch back and forth repeatedly between multiple different API levels, in order to use the behavior of multiple different API levels around the same time, or something like that.

The reason I don't think that is a priority is because I can't think of any real-world situation where that would be needed, but it is an interesting thought, so maybe if one of the people who needs to target an alternative API level needs that, they could explain how and why so their use case can be considered here.

Anyway, I feel that this fix is ​​a bit strange and cannot be considered to solve 23401.

To explain a clarification, a while ago, I changed the description to say "fixes partly 23401" instead of "fixes 23401" because it arguably does not completely fix 23401.

I will merge this in 24 hours, so that the NDK r29 update can be rebased on it.