mingw-w64 null event loop

spoo spoo at zarbosoft.com
Sat Nov 23 02:46:33 CET 2013


> On November 21, 2013 at 9:26 AM Marc Lehmann <schmorp at schmorp.de> wrote:
>
>
> On Thu, Nov 21, 2013 at 06:44:51PM +0900, Spoo <spoo at zarbosoft.com> wrote:
> > I installed mingw-w64-gcc on Arch Linux (using the aur package). I
> > configured libev with --host=x86_64-w64-mingw32 (no other configure flags
> > except prefix).
> >
> > In my code I try ev_default_loop(0) and then ev_new_loop(0) and both return
> > null/0/false. Libev is static linked. I just tried it on a fresh windows 7
> > install and there are no env variables set relating to libev. It also fails
> > on my old windows install and in wine.
> >
>
> ev_default_loop returns 0 when none of the backend worked. since select
> and poll always succeed, I guess those two backends are not compiled
> in. What configure output do you get? Do you have the required header
> files and working select/poll?
>

Thanks!  I'm not sure what you mean by required header files - configure didn't
abort so I assumed I had everything but maybe that was incorrect.  I checked the
config.log and indeed, it didn't find poll or select (it only tried sys/select.h
and not winsock2.h).
 
I think my initial reading of the documentation was too shallow, so I re-read
it.  In the win32 compatibility section, you wrote:
"A typical way to use libev under windows is to embed it (see the embedding
section for details) and use the following evwrap.h header file instead of ev.h"
 
I tried that and got several errors when compiling:
-------------
$x86_64-w64-mingw32-g++ a.cxx evwrap.c
In file included from ev.c:1280:0,
                 from evwrap.c:2:
ev_win32.c: In function ‘ev_tstamp ev_time()’:
ev_win32.c:149:14: error: declaration of ‘ev_tstamp ev_time()’ has a different
exception specifier
 ev_time (void)
              ^
In file included from evwrap.h:4:0,
                 from evwrap.c:1:
ev.h:530:23: error: from previous declaration ‘ev_tstamp ev_time() throw ()’
 EV_API_DECL ev_tstamp ev_time (void) EV_THROW;
                       ^
In file included from evwrap.c:2:0:
ev.c: At global scope:
ev.c:1531:31: warning: ‘ev_default_loop_ptr’ initialized and declared ‘extern’
[enabled by default]
   EV_API_DECL struct ev_loop *ev_default_loop_ptr = 0; /* needs to be
initialised to make it a definition despite extern */
                               ^
ev.c: In function ‘void evpipe_write(ev_loop*, volatile sig_atomic_t*)’:
ev.c:2168:19: error: cannot convert ‘WSABUF* {aka _WSABUF*}’ to ‘char*’ in
assignment
           buf.buf = &buf;
-------------
 
If I compile it with gcc instead it works (compiles).
 
Upon running my original program, I get an abort with: "(libev) error creating
signal/async pipe".
 
In retrospect, there were some sections in the documentation and configuration
that were unclear.  I think that elaborating/rewriting the following quotes
would help potential and new users significantly.
 
"A typical way to use libev under windows is to embed it (see the embedding
section for details) and use the following evwrap.h header file instead of ev.h"
To me, the use of the word "typical" does not indicate necessity.  Also, since
these steps are necessary for use on Windows, it seems unintuitive that they are
not integrated into the libev project and are not the default behavior on the
Windows platform.
 
"There is no supported compilation method available on windows except embedding
it into other applications."
I thought this meant that a dynamic library could not be used.  When doing a
default configure and compile, only a static lib was produced, which seemed to
meet the criteria.  Now I wonder if this isn't referring to the evwrap
procedure.
 
"Libev still offers limited functionality on this platform in the form of the
EVBACKEND_SELECT backend, and only supports socket descriptors." and "libev
tries its best, but under most conditions, signals will simply not work."
Initially, I did not assume there was a connection between "only supports socket
descriptors" and async watcher since I have no idea how that watcher is
implemented.  If "only supports socket descriptors" means "only supports io
watchers, timer watchers, and periodic watchers, and within the io watcher
subset, only supports socket io watchers" then this contradicts the second
quote, which implies that under some conditions signal watchers will work.
 
I might have misunderstood something, so please call me out if my conclusion is
incorrect.  If Windows support is necessary, libev provides no benefit over raw
select other than efficiency improvements on some *nix platforms.  Since async
is important for my program (responsivity to user inputs) I'll either need to
implement a solution myself or find another cross-platform event wrapper
library.
 
Cheers,
Rendaw



More information about the libev mailing list