This is an archive of the discontinued LLVM Phabricator instance.

Define __ANDROID_API__ for all Android builds.
ClosedPublic

Authored by srhines on Nov 7 2016, 9:41 PM.

Details

Summary

Bug: https://llvm.org/bugs/show_bug.cgi?id=30940

This macro (along with ANDROID) should always be defined for Android
targets. We set it to the major (only) version of the Android API being
compiled for. The Android version is able to be set as an integer suffix
for any valid Android target.

Diff Detail

Repository
rL LLVM

Event Timeline

srhines updated this revision to Diff 77141.Nov 7 2016, 9:41 PM
srhines retitled this revision from to Define __ANDROID_API__ for all Android builds..
srhines updated this object.
srhines added subscribers: danalbert, eugenis, pirama, cfe-commits.

This macro (along with ANDROID) should always be defined for Android targets.

What if only arm-linux-androideabi (without a version) is specified? We should be falling back to the old behavior (don't defined __ANDROID_API__) when that happens since that's what every build system out there is going to be relying on.

This macro (along with ANDROID) should always be defined for Android targets.

What if only arm-linux-androideabi (without a version) is specified? We should be falling back to the old behavior (don't defined __ANDROID_API__) when that happens since that's what every build system out there is going to be relying on.

It is defines with a value of 0. This allows you to actually do something better, IMO. You can now handle old or new NDKs by seeing if this is defined to a special level, or 0 for no level, or not defined at all (old toolchain, build rules, etc.). Does that make sense?

It is defines with a value of 0. This allows you to actually do something better, IMO.

Can we stick with undefined? That's historically how things have been, and I'm sure there's code out there depending on that (I had actually written a test that would depend on this a few weeks ago).

If we do want to do this, we're going to have to redo the legacy headers as they current define this unconditionally (-Wmacro-redefined). I suppose we probably don't have to worry about people using a new clang with an old NDK, so we could just change that, but I don't really see an argument for setting it to zero.

This is a good change, but I don't think it is the right fix for PR30940. Instead of handling this in the NDK, we should change *::getIRStackGuard to fallback to __stack_chk_guard when targeting an old version.

srhines updated this revision to Diff 77236.Nov 8 2016, 12:24 PM

Switched to conditionally defining ANDROID_API instead.

This is a good change, but I don't think it is the right fix for PR30940. Instead of handling this in the NDK, we should change *::getIRStackGuard to fallback to __stack_chk_guard when targeting an old version.

Right, this is only addressing part of the problem related to that issue. I can probably put together a follow up to address the rest of the bug, although I am not all that familiar with __stack_chk_guard, so testing might be a problem.

danalbert accepted this revision.Nov 8 2016, 12:47 PM
danalbert added a reviewer: danalbert.

LGTM

This revision is now accepted and ready to land.Nov 8 2016, 12:47 PM
eugenis accepted this revision.Nov 8 2016, 12:50 PM
eugenis added a reviewer: eugenis.

LGTM

This revision was automatically updated to reflect the committed changes.

Ugh, phabricator dropped my updated commit message, so that is completely wrong now. Oh well. I guess I will just use repo/gerrit for staging things in the future (and get consensus there) before asking for any upstream reviews.