-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linux_android_with_fallback: avoid dlsym #598
Conversation
r? @newpavlov |
4f11144
to
792ac28
Compare
@newpavlov I've added a test now to check that musl works when /dev/urandom isn't available. |
I don't think it's a good approach to solving this issue. We probably should write a MUSL-specific version of the As for |
That's exactly what this does.
|
@newpavlov thoughts? |
I created #602 as a smaller alternative. As for testing, I will do it in a different PR slightly differently. |
792ac28
to
92753dd
Compare
I've backed out the test. I've changed the approach here - now the check for The build script needs a bit of refinement - the check is not necessary on all platforms, but I want to get CI results and also to let you have a look. |
d1f2012
to
49929b7
Compare
The dlsym-based getrandom detection added in commit 869a4f0 ("linux_android: use libc::getrandom") assumes dynamic linking, which means it never works properly on musl where static linking is the norm. Replace this with build-time feature checking by attempting to link to getrandom in build.rs.
49929b7
to
8c94108
Compare
Trying to detect |
The only target we handle that may or may not have
Cross-compilation already works correctly with this approach. We are using the user's native compiler for the target. |
Fixed in #602 |
Please reopen this. I'm going to rebase it - it is a separate proposal to the fix in #602. This is about removing dlsym entirely. |
I would prefer to keep using dlsym on non-MUSL targets. Alternatively, we could use raw syscalls similarly to |
Let's continue the conversation over code, please. I'd appreciate some reasoning. Why is dlsym preferable? |
It's much simpler than your approach based on build scripts. It does not add the |
Remember that this code is used only on Android and MUSL. For Android, you always use the NDK, so this doesn't apply. In MUSL, support for getrandom was added 7 years ago. Who is building with a 7 year old MUSL? The benefits of this approach are that it's making the resulting code faster (no indirect call), the implementation in I don't understand why the build dependency on cc is a meaningful downside. |
You are forgetting about GNU targets which are much more popular than MUSL and Android targets combined. With the current approach I can compile my project on RHEL 7 and get a binary which properly uses the
As I wrote here, this is a vanishingly small difference in our case. And if you care about it or if you find
|
Ah! I missed the fact that this implementation is used on GNU (on some architectures).
Indeed, this makes more sense when we talk about GNU targets (Android is always cross-compiled). I agree there's no way to support GNU targets without dlsym or weak linking, which isn't possible on nightly. |
See the commit message.
Fixes #600.