Re: [PATCH] Fixed Android support
On Wed, May 31, 2017 at 10:18:13PM -0700, enh wrote: > >> presence of EPOLL_CLOEXEC doesn't necessarily imply the presence of > >> epoll_create1 on Android. This is because (as of NDK r15) we're using > > > > If android uses header files that don't match it's libc *on purpose* then > > android is way beyond broken. > > no, these are the Android libc header files. I don't quite understand what you are trying to say - "no" to what? The header files match (but don't match?), or it's not on purpose (then it should be fixed), or something else? From what you said the header files don't match the libc *on purpose*. If it's not on purpose then open a bug against your header files and fix them. Or fix the libc. > > configure is optional for libev, so a "proper" test wouldn't work. > > i'm not sure what you're saying here: you already use configure and > have correctly used HAVE_ tests for other functions. I am not sure what you mean with "correctly", but the point is that configure is *optional*, a user doesn't have to run it and still can expect it to work. > > This is clearly a bug in the android headers, and since it apparently only > > affects old versions, I don't think it makes sense to make things worse > > for users of higher quality platforms that have correct header files. > > no, it's the opposite way round. older versions of Android didn't have > epoll_create1. newer versions do. That's exactly what I said: the problem only affects old versions, because the headers don't match the old versions. They do match the new version(s) apparently, don't they? > constant. (the constants come from the upstream kernel uapi header But libev does not include those headers - it's the responsibility of the header files to be consistent and correct. If you don't know how, you can look at how normal GNU/Linux distributions solve this problem - they either deliver corretc header files or consider this a bug. > > I would suggest opening a bug against android so these obvious bugs get > > fixed instead of trying to push patches to the rest of the world to work > > around it. > > i manage the Android libc/NDK team :-) That's great - you need to take responsibility then and fix your project, no? > this change is a result the NDK catching up with the platform headers > after being years behind. Then this would be the perfect opportunity to fix your header files, no? In a more general note, since the reason for all these issues is google's anti-freedom stance (there is no *technical* need to provide a low-quality and incompatible libc on android), google is responsible for making it work without pushing their maintenance work on others just because others work for free. Again, it's a matter of taking responsibility - you created the mess, you need fix it. Greetings, -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
Re: [PATCH] Fixed Android support
On Wed, May 31, 2017 at 8:15 PM, Marc Lehmann wrote: > On Tue, May 30, 2017 at 05:28:07PM -0700, enh wrote: >> The attached patch fixes Android NDK bug >> https://github.com/android-ndk/ndk/issues/396 --- basically the >> presence of EPOLL_CLOEXEC doesn't necessarily imply the presence of >> epoll_create1 on Android. This is because (as of NDK r15) we're using > > If android uses header files that don't match it's libc *on purpose* then > android is way beyond broken. no, these are the Android libc header files. >> Gingerbread, you'll have all the enums and macros and structs from >> Marshmallow and O. so you actually need a proper configure test for >> epoll_create1. > > configure is optional for libev, so a "proper" test wouldn't work. i'm not sure what you're saying here: you already use configure and have correctly used HAVE_ tests for other functions. > This is clearly a bug in the android headers, and since it apparently only > affects old versions, I don't think it makes sense to make things worse > for users of higher quality platforms that have correct header files. no, it's the opposite way round. older versions of Android didn't have epoll_create1. newer versions do. if you want to keep building on NDK r15 and later, you'll need to check for the function, not the constant. (the constants come from the upstream kernel uapi header files, and a given Android release doesn't mandate any corresponding kernel version, so there's no way to version that.) > I would suggest opening a bug against android so these obvious bugs get > fixed instead of trying to push patches to the rest of the world to work > around it. i manage the Android libc/NDK team :-) this change is a result the NDK catching up with the platform headers after being years behind. > Unrelated, the __ANDROID__ change will be in the next release. > > Greetings, > > -- > The choice of a Deliantra, the free code+content MORPG > -==- _GNU_ http://www.deliantra.net > ==-- _ generation > ---==---(_)__ __ __ Marc Lehmann > --==---/ / _ \/ // /\ \/ / schm...@schmorp.de > -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
Re: [PATCH] Fixed Android support
On Tue, May 30, 2017 at 05:28:07PM -0700, enh wrote: > The attached patch fixes Android NDK bug > https://github.com/android-ndk/ndk/issues/396 --- basically the > presence of EPOLL_CLOEXEC doesn't necessarily imply the presence of > epoll_create1 on Android. This is because (as of NDK r15) we're using If android uses header files that don't match it's libc *on purpose* then android is way beyond broken. > Gingerbread, you'll have all the enums and macros and structs from > Marshmallow and O. so you actually need a proper configure test for > epoll_create1. configure is optional for libev, so a "proper" test wouldn't work. This is clearly a bug in the android headers, and since it apparently only affects old versions, I don't think it makes sense to make things worse for users of higher quality platforms that have correct header files. I would suggest opening a bug against android so these obvious bugs get fixed instead of trying to push patches to the rest of the world to work around it. Unrelated, the __ANDROID__ change will be in the next release. Greetings, -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
