-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Update NDK to r15b and add some missing symbols #634
Conversation
Thanks for the PR! I think a number of the changes here are breaking changes, right? Unfortunately we won't be able to land those at that this time, but mind detailing what's breaking? |
Yes, there are some breaking changes, but unfortunately, according to Google:
So the current binding is based on partially broken headers.
===
long st_atime; \
unsigned long st_atime_nsec; \
long st_mtime; \
unsigned long st_mtime_nsec; \
long st_ctime; \
unsigned long st_ctime_nsec; \ as changed to: struct timespec st_atim; \
struct timespec st_mtim; \
struct timespec st_ctim; \ where struct timespec {
time_t tv_sec;
long tv_nsec;
}; There are some /* Compatibility with older versions of POSIX. */
#define st_atime st_atim.tv_sec
#define st_mtime st_mtim.tv_sec
#define st_ctime st_ctim.tv_sec
/* Compatibility with glibc. */
#define st_atimensec st_atim.tv_nsec
#define st_mtimensec st_mtim.tv_nsec
#define st_ctimensec st_ctim.tv_nsec Notice the change from === Some functions have an argument that changed from Maybe for these, we could let the const but we need to change the headers in the CI too. === get/setpriority has a signedness change for their int getpriority(int, int); changed to int getpriority(int, id_t); where We could still keep the old type, as they have the same size. ===
In Android 32bits, these are exactly the same ABI but the test fail because it's not the same C API. So, we could avoid making a breaking change for all these but it requires to keep the binding to broken definitions. For example, the I don't mind waiting for the crate going to release a breaking change if that allow the change to be cleaner. Is that planned in a foreseeable future ? |
Unfortunately no, I think we shouldn't try to fix it as soon as possible. |
I set With the header modification, we still check if the rust libc points to the same function as the C one. |
Another idea if the current solution is inacceptable : Maybe we should check how to undefine
So maybe we should disable I'm not certain what currently makes _GNU_SOURCE enabled, but it should be possible to disable it ? |
It seems to be defined by the compiler itself. #include <stdio.h>
int main() {
#if defined(_GNU_SOURCE)
printf("_GNU_SOURCE\n");
#else
printf("non GNU\n");
#endif
} On my machine, compiling this program with Maybe we could just add |
Thanks for the cataloging @ndusart! I definitely agree that we should fix all these bindings at the next available chance, but for now with libc 0.1 we can't change these. In that sense I think the question is best framed as 'how do we verify these now and check them later'? It's quite a relief that nothing here is an ABI-breaking change, which is good! In that sense, I see a few options here:
Or... something along those lines. Stuff like switching to For |
Beside the signedness changes, there is no ABI breaks indeed. And according to the new headers (which should apply for all Android version even older ones), these functions and So I agree we could just ignore these tests until the next major release. |
Sorry, didn't test for android 64 bits and some functions specific to 64 bits have changed as well. I'll check for these and add them to ingoring list as the other. I'll append them to the list of changes and report an issue for the next major version of libc. |
Funnily, the symbols that have problems now in // Some weirdness in Android
extern {
// address_len should be socklen_t, but it is c_int!
pub fn bind(socket: ::c_int, address: *const ::sockaddr,
address_len: ::c_int) -> ::c_int;
// the return type should be ::ssize_t, but it is c_int!
pub fn writev(fd: ::c_int,
iov: *const ::iovec,
iovcnt: ::c_int) -> ::c_int;
// the return type should be ::ssize_t, but it is c_int!
pub fn readv(fd: ::c_int,
iov: *const ::iovec,
iovcnt: ::c_int) -> ::c_int;
// the return type should be ::ssize_t, but it is c_int!
pub fn sendmsg(fd: ::c_int,
msg: *const ::msghdr,
flags: ::c_int) -> ::c_int;
// the return type should be ::ssize_t, but it is c_int!
pub fn recvmsg(fd: ::c_int, msg: *mut ::msghdr, flags: ::c_int) -> ::c_int;
} Those weirdness are specifically what are fixed by the new headers in NDK. For For the other functions, they return The solution could be also just to add them to the skipping list and wait the next major relase for the real fix. @alexcrichton Do you agree ? And what about |
@alexcrichton I ignored the breaking changes and the CI is passing now. I just had to update the sys-img used for testing x86_64 from API 21 to 24, so that it contains the new functions (especially |
src/unix/notbsd/android/mod.rs
Outdated
@@ -562,6 +565,7 @@ pub const TIOCMBIC: ::c_int = 0x5417; | |||
pub const TIOCMSET: ::c_int = 0x5418; | |||
pub const FIONREAD: ::c_int = 0x541B; | |||
pub const TIOCCONS: ::c_int = 0x541D; | |||
pub const CLONE_NEWCGROUP: ::c_int = 0x02000000; |
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.
I promise this is the last nitpick :P
Maybe this should be moved along with https://github.com/rust-lang/libc/search?utf8=%E2%9C%93&q=CLONE_NEWCGROUP&type= to be with the others ?
Line 689 in 83f5543
pub const CLONE_VM: ::c_int = 0x100; |
It's not defined in sparc64, but I strongly believe it to be a bug since I can't find any mention of this flag not being defined on SPARC for linux.
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.
I agree, these constants definitely should be merged.
The constant is defined on all architectures: https://github.com/torvalds/linux/blob/master/include/uapi/linux/sched.h
Correct yeah, if the typedefs all resolve to the same thing then it's fine for us to change the names here.
Gee this is terrifying :( Ok in the meantime though this looks great, thanks for the effort @ndusart! Mind also opening an issue detailing the breakage that we need to cover for the next major release of libc? @bors: r+ |
📌 Commit 4abc3ce has been approved by |
Update NDK to r15b and add some missing symbols Use the new unified headers of the NDK and add some missing symbols for Android. Fixes #632
@@ -534,6 +539,16 @@ fn main() { | |||
// On Mac we don't use the default `close()`, instead using their $NOCANCEL variants. | |||
"close" if apple => true, | |||
|
|||
// Definition of those functions as changed since unified headers from NDK r14b |
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.
This should be "have changed", correct?
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.
Yes, sorry for the typo. Do you think we should fix it ?
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.
Nah, already merged. Maybe if you create a new PR for #641.
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.
Yeah, and when fixing that issue, we'll certainly reword that comment in any way :)
☀️ Test successful - status-appveyor, status-travis |
Done, created #641 |
Use the new unified headers of the NDK and add some missing symbols for Android.
Fixes #632