std: Fix linking against signal on Android
#32415
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
☔ The latest upstream changes (presumably #32390) made this pull request unmergeable. Please resolve the merge conflicts. |
0b86f4f to
c5b9b24
Compare
|
@bors: r+ |
|
📌 Commit c5b9b24 has been approved by |
|
⌛ Testing commit c5b9b24 with merge b60f122... |
|
💔 Test failed - auto-linux-64-x-android-t |
|
Looks like Gee I wonder why Ok, so that strategy doesn't work on Android, but apparently |
Currently the minimum supported Android version of the standard library is API level 18 (android-18). Back in those days [1] the `signal` function was just an inline wrapper around `bsd_signal`, but starting in API level android-20 the `signal` symbols was introduced [2]. Finally, in android-21 the API `bsd_signal` was removed [3]. Basically this means that if we want to be binary compatible with multiple Android releases (oldest being 18 and newest being 21) then we need to check for both symbols and not actually link against either. This was first discovered in rust-lang/libc#236 with a fix proposed in rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so Rust crates at large continue to be compatible with newer releases of Android and crates, like the standard library, that want to opt into older support can continue to do so via similar means. Closes rust-lang/libc#236 [1]: https://chromium.googlesource.com/android_tools/+/20ee6d20/ndk/platforms/android-18/arch-arm/usr/include/signal.h [2]: https://chromium.googlesource.com/android_tools/+/fbd420/ndk_experimental/platforms/android-20/arch-arm/usr/include/signal.h [3]: https://chromium.googlesource.com/android_tools/+/20ee6d/ndk/platforms/android-21/arch-arm/usr/include/signal.h
c5b9b24 to
9c462b8
Compare
|
⌛ Testing commit 9c462b8 with merge 69d3a19... |
|
💔 Test failed - auto-linux-64-x-netbsd |
|
Hm this may end up being difficult to land and have ramifications on the rest of the Rust ecosystem. This updates the libc submodule to include changes in rust-lang/rfcs#1529 which is starting to link a new library by default. I'm wary of this causing breakage on bots beyond ours, so we should keep our eyes peeled and be ready to revert if need be. |
|
@bors: retry On Tue, Apr 5, 2016 at 3:27 AM, bors notifications@github.com wrote:
|
std: Fix linking against `signal` on Android Currently the minimum supported Android version of the standard library is API level 18 (android-18). Back in those days [1] the `signal` function was just an inline wrapper around `bsd_signal`, but starting in API level android-20 the `signal` symbols was introduced [2]. Finally, in android-21 the API `bsd_signal` was removed [3]. Basically this means that if we want to be binary compatible with multiple Android releases (oldest being 18 and newest being 21) then we need to check for both symbols and not actually link against either. This was first discovered in rust-lang/libc#236 with a fix proposed in rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so Rust crates at large continue to be compatible with newer releases of Android and crates, like the standard library, that want to opt into older support can continue to do so via similar means. Closes rust-lang/libc#236 [1]: https://chromium.googlesource.com/android_tools/+/20ee6d20/ndk/platforms/android-18/arch-arm/usr/include/signal.h [2]: https://chromium.googlesource.com/android_tools/+/fbd420/ndk_experimental/platforms/android-20/arch-arm/usr/include/signal.h [3]: https://chromium.googlesource.com/android_tools/+/20ee6d/ndk/platforms/android-21/arch-arm/usr/include/signal.h
Currently the minimum supported Android version of the standard library is
API level 18 (android-18). Back in those days 1 the
signalfunction wasjust an inline wrapper around
bsd_signal, but starting in API levelandroid-20 the
signalsymbols was introduced 2. Finally, in android-21the API
bsd_signalwas removed 3.Basically this means that if we want to be binary compatible with multiple
Android releases (oldest being 18 and newest being 21) then we need to check
for both symbols and not actually link against either.
This was first discovered in rust-lang/libc#236 with a fix proposed in
rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so
Rust crates at large continue to be compatible with newer releases of Android
and crates, like the standard library, that want to opt into older support can
continue to do so via similar means.
Closes rust-lang/libc#236