-
Notifications
You must be signed in to change notification settings - Fork 666
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
Allow nix to compile on android #631
Conversation
f82dbf1
to
3513dad
Compare
src/sys/signal.rs
Outdated
@@ -210,6 +211,19 @@ libc_bitflags!{ | |||
} | |||
} | |||
|
|||
#[cfg(target_os = "android")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These need doc comments. Also, if you search the libc
crate you'll see these are available on Linux and all BSD platforms. We shouldn't artificially restrict them to just android
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are still available on other platforms, just defined as libc::c_int above ? CF line 201
Maybe I should use cfg_if! to make it clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth noting that this change is necessary because of rust-lang/libc#511
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're defined as c_int
for all platforms.
Since you mentioned the upstream issue, please also add a FIXME
that links to the upstream issue and states what can be done when it's resolved. We need to track these tasks in the code, not just here in the PRs.
So there's another symbol that's apparently missing from android :
When we try to compile something for android, we get a linker error saying that Now, because the bionic |
More problems, this time for the target https://github.com/nix-rust/nix/blob/master/src/sys/socket/consts.rs#L43 is marked as |
7ac2dc7
to
7c609de
Compare
It should now be possible to compile binaries using nix for both arm-linux-androideabi and aarch64-linux-android. Should I document every |
@roblabla There are basically two categories of things here you're asking about, one is things that currently fail when testing on Android that shouldn't and things that shouldn't be tested on Android. I'd prefer to wait until upstream is fixed so that we only have cases of the latter. Those don't need to be documented. If we have things that can't currently be tested because they're blocking on upstream, those need to be documented. But like I said, I'd rather wait until upstream is fixed to merge this PR so that we only have "good" fixes here. |
The only change that'll ever be fixed by libc is the use of 'as' in the bitflags though, along with missing symbols.
I'll try digging what symbols are missing in libc compared to the most recent version of android, so we have a clearer picture of the situation.
…On June 29, 2017 6:29:12 AM GMT+02:00, Susurrus ***@***.***> wrote:
@roblabla There are basically two categories of things here you're
asking about, one is things that currently fail when testing on Android
that shouldn't and things that shouldn't be tested on Android. I'd
prefer to wait until upstream is fixed so that we only have cases of
the latter. Those don't need to be documented. If we have things that
can't currently be tested because they're blocking on upstream, those
need to be documented. But like I said, I'd rather wait until upstream
is fixed to merge this PR so that we only have "good" fixes here.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#631 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
Yes, well |
Linking rust-lang/libc#632 since it seems to contain some items of interest. |
@roblabla We now have all android targets being built in CI, so if you rebase this you can see how well things will compile on those targets. Probably not worth doing so until rust-lang/libc#632 settles down, however. |
@roblabla rust-lang/libc#632 is fixed, we could remove some of the |
With rust-lang/libc#634 now merged, most of the constants are now defined. The only ones left are :
They should be defined though, as a quick grep -R reveals they are in the unified headers, under |
@roblabla I added those constants in rust-lang/libc#639 already as I saw they were needed for Android and I was already adding socket constants as part of #636. |
So give this thing a rebase and remove some of those |
c890644
to
b63494d
Compare
rust-lang/libc#642 is necessary now |
b63494d
to
9936533
Compare
I'd also like to move Android builds to Tier 2 as part of this. Could you modify the README and also |
ff15228
to
f75f03b
Compare
Should be fine now |
Could you better document your changes to the I'd also prefer your changes to |
f75f03b
to
eceada4
Compare
Is this better ? I basically only added one use-case, just split accross 2 arms to support the trailing comma on the last ident. |
Right, so this change caused the build to fail on arm(v7)-unknown-linux-gnueabi because libc doesn't define those flags on arm. rust-lang/libc#644 will fix this failure. For the i686 and x86_64 android, there are a bunch of type failures. Which is surprising because there isn't much in the arch-specific files of libc (https://github.com/rust-lang/libc/blob/master/src/unix/notbsd/android/b32/arm.rs). I'll investigate. |
The failures on Android with Intel-cpu are due because the test suite is using rustc 1.13 which has no support at all for x86_64-linux-android and for which std was broken for i686-linux-android (see fix), this fix was introduced in version 1.18 of rust. So the explanation was that I think x86_64-linux-android is not considered stable yet, libc still use the beta channel for testing it. I could also advise you to test (at least the build phase) locally on your machine with the latest rustc for the different targets. You won't have to commit just to test and you'd have seen that difference. |
eceada4
to
51aae0f
Compare
Ah I see. So I bumped the minimum version to 1.18 for i686/x86_64. I also updated the libc PR to also define I think this should be everything necessary. |
51aae0f
to
55bec60
Compare
@roblabla Love the separate macro commit, thanks for that. That let me cherry-pick it into #527, as I needed that functionality as well. This is pretty close to being mergeable:
|
Please add those CHANGELOG entries in with the corresponding commits. If you're feeling particularly diligent, you could also reorder the 2 last commits. I like to have commits ordered such that building things will always succeed. This means fixing the errors and then requiring builds to pass for the fixed target. |
@Susurrus actually, the commits are in the right order. Github interface is just confused, probably because of all the rebase and push --force ? https://github.com/roblabla/nix/commits/feature-androidWorks |
f8a6951
to
552fccf
Compare
This is necessary because certain flags in libc have different types, generally due to a mistake when adding the flags to the libc. See rust-lang/libc#511 for an example of such a discrepency.
Done. |
LGTM, thanks for all your hard work! bors r+ |
Build succeeded |
Fixes #313