Skip to content

Breaking Android changes for libc 1.0 #3875

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
tgross35 opened this issue Aug 29, 2024 · 1 comment
Open

Breaking Android changes for libc 1.0 #3875

tgross35 opened this issue Aug 29, 2024 · 1 comment

Comments

@tgross35
Copy link
Contributor

#641 listed some things that we may want to break when libc gets a 1.0. #634 addressed some of it, but I don't believe that is everything since (iiuc) it went into a 0.2.x release.

We are ramping up toward a 1.0 release. Is there anything else incorrect that we may want to change? Cc @ndusart since you authored the issue and PR, @maurer since I think you're the main Android maintainer at this point.

@tgross35 tgross35 added this to the 1.0 milestone Aug 29, 2024
@ndusart
Copy link
Contributor

ndusart commented Aug 29, 2024

That's a looong time ago for me 😅 , I need to get back into this crate internals to provide meaningful information.

From a quick glimpse, I would say that it should be best to look into the symbols that are skipped from the libc-test and see if they fails because they are just unaligned with latest headers or if the skip is there for a valid reason.

Most of the skips I introduced are gone (and comments about these skips are now weirdly in the solaris part of the test ^^) so I suppose most breaking changes have already been done (e.g: 7d5e632)

I cannot provide the necessary effort to be exhaustive in this matter though and I didn't need to do any Android native development for a while so I cannot say easily if libc crate is off for the latest versions of NDK.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants