On Wed, May 31, 2017 at 10:18:13PM -0700, enh <e...@google.com> 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
