Dynamically look up backtrace(3) on Android.

[grynspan]

The backtrace() function on Android was added with API level 33, but at least some external Android builds target earlier Android NDKs, so we'll dynamically look up the function. If it's not present or dynamic loading isn't available, we just produce an empty backtrace.

See: https://cs.android.com/android/_/android/platform/bionic/+/731631f300090436d7f5df80d50b6275c8c60a93:libc/include/execinfo.h;l=52

Resolves #1135.

Checklist:

• Code and documentation should follow the style of the Style Guide.
• If public symbols are renamed or modified, DocC references should be updated.

[finagolfin]

Should we just wait for #availability checking to be added for Android, swiftlang/swift#84574? Seems like Mads is close to getting that working; we simply disable this backtrace code in our Android SDK bundles for now.

[grynspan]

No, because the signature is not consistent (optionality has changed) between the different toolchains floating around out there. So even with #available, I wouldn't be able to type the function call correctly.

[finagolfin]

The signature issue is irrelevant: the only one that matters is the one currently in Bionic. The other signature comes from my Android SDK bundle, which uses a Termux library that was backported to API 24, but I'm sunsetting my bundle in favor of the official SDK bundle that we're working on, which will simply delegate to the Bionic headers in the NDK.

[grynspan]

You're the domain expert, so if you think we should wait, I defer to you. However this change will also work even without #available() (in case that doesn't land) and should work with older compilers.

[finagolfin]

I'm not too worried about backwards compatibility, particularly considering I only got this library building for Android earlier this year.

I'm certainly no expert on dlsym() or #available, neither of which I've ever used, but I thought that if we are on the verge of a Swift-native solution, better to use that: what do you think?

Thanks for working on this, but that was my only concern.

[grynspan]

I think it really depends on how long until #available is functional on Android. If it's going to be a long time, this solution is ready now and will be fully functional. If it's ready to ship next week, then yeah we should wait.

[finagolfin]

Mads is working on it and while he hit some stumbling blocks in that pull, hopefully we can add it soon, let's see.

[stmontgomery]

I have no particular opposition to this landing in the short term, even if we later adopt a better availability check

[grynspan]

I'll leave it to @finagolfin to decide.

[finagolfin]

I'd rather avoid these old C methods if #available is around the bend, let's see what Mads comes up with this month.