On Tue, Jun 26, 2012 at 08:26:01AM -0400, Jamal Hadi Salim j...@mojatatu.com
wrote:
In the noise making that claim i lost the main point:
The semantics have changed.
Not really.
Now when i do epoll_create on new kernel, that param is ignored
regardless of whether i have a new or old glibc.
On Tue, 2012-06-26 at 00:01 +0200, Marc Lehmann wrote:
As you can see it translates to epoll_create1(0)
As it should, no sign of it being phased out here.
Agreed - what i showed is backward compat support (typically this
is how i have seen things get phased out).
In the noise making that
On Mon, Jun 25, 2012 at 09:12:02AM -0400, jamal h...@cyberus.ca wrote:
Not sure about glibc emulating or what it means when you pass 255 to
epoll_create being emulated, but here's what the kernel does when you
call syscall epoll_create:
So the kernel fully supports epoll_create after all
and the kernels;- If i start maintaining personal OCD forks
I am defeating the purpose. So it seems to me my best way forward is to
just say use glibc 2.9 and above.
cheers,
jamal
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi
is to
just say use glibc 2.9 and above.
The best way for you would be to use glibc 2.8 or newer - that will just
run on all newre libcs, until you hit a libc that has been deliberately
compiled without backwards compatibility. That would solve all technical
problems you have, unless you really have
On Tue, 2012-06-19 at 20:33 +0200, Marc Lehmann wrote:
Since the only problem you mentioned is that you don't like the correct
(and in fatc, only) solution to your problem, I would say your problem is
not technological, but psychological in nature - nothing libev does can
help you with that.
On Tue, Jun 19, 2012 at 8:33 PM, Marc Lehmann schm...@schmorp.de wrote:
in general, glibc itself has no forward compatibility,
On Wed, Jun 20, 2012 at 2:00 PM, jamal h...@cyberus.ca wrote:
I cant recompile on every possible permutation of eglibc/uclibc/glibc
unfortunately - so that idea is
On Wed, 2012-06-20 at 14:13 +0200, Zsbán Ambrus wrote:
How about backwards compatibility? Could you compile the program only
on a system with the older glibc version, and run it on a system with
newer glibc?
That would work to solve the problem - but i would miss out on the
optimizations
On Wed, Jun 20, 2012 at 08:00:54AM -0400, jamal h...@cyberus.ca wrote:
I cant recompile on every possible permutation of eglibc/uclibc/glibc
There are exactly two permutations of thes elibraries: uclibc and
glibc/eglibc. And yes, if you want to support uclibc, you have to
recompile. Just as you
On Fri, Jun 15, 2012 at 06:13:18AM -0400, jamal h...@cyberus.ca wrote:
glibc 2.9 and above added support for EPOLL_CLOEXEC + IN_CLOEXEC
If i compile (and app-embed) libev on a system with glibc 2.9
and try to run it on a system which is glibc 2.9
there is failure to load (since we expect
There's probably an easy way to do this. Note: This is not a libev
issue perse, rather a glibc compat issue.
glibc 2.9 and above added support for EPOLL_CLOEXEC + IN_CLOEXEC
If i compile (and app-embed) libev on a system with glibc 2.9
and try to run it on a system which is glibc 2.9
11 matches
Mail list logo
