mingw compat note
rogerpack2005 at gmail.com
Thu Nov 13 04:03:32 CET 2008
What seems to happen is that when I'm within the 'main' ruby dll
sockets work like a champ, then when control transfers to the libev
side for some reason all socket functions don't work. You can't even
bind to a fresh socket there or anything.
My latest guess is that there is some inconsistency with linking to
-lws2_32 within two separate .so files and expecting sockets to work
within both. Tough to tell though.
Oh well...cruddy wiindows :)
On Wed, Nov 12, 2008 at 2:40 AM, Roger Pack <rogerpack2005 at gmail.com> wrote:
> Note that for some reason, adding those extra includes fixed it for
> "normal" build in mingw but broke an embedded build using the same.
>>> And for some reason it didn't give me a base by default so I had to
>>> hard code in EV_USE_SELECT
>> What's a base?
>> Did you run configure when building the library or was it somehow
>> embedded? In the latter case, the embedding app has to provide configuraiton
> heh guess it's called a backend. This is with msys configure.
> Adding the
> #define EV_STANDALONE /* keeps ev from requiring config.h */
> #define EV_SELECT_IS_WINSOCKET 1 /* configure libev for windows select */
> to event.c/ev.c seemed to force it to work :)
> [on non-embedded]
>> A quick google search about mingw didn't give me a decisive result on what
>> type sockets have, but I have the impression that it uses operating system
>> handles (HANDLE, SOCKET), not file descriptors (int).
>> Since windows doesn't seem to have a standard API (mingw is incompatible
>> to pure win32 is incompatible to posix is incompatible to cygwin etc.),
>> libev needs to be told how the environment converts file descriptors to
>> socket handles (_get_osfhandle) and how to get file descriptors out of
>> socket handles (e.g. _open_osfhandle).
> Wow you made that easy on me :)
> #define EV_FD_TO_WIN32_HANDLE(s) (s)
> to the top of ev.c helped it now work! Rock on!
> Unfortunately this doesn't seem to work when used with rev--rev
> currently creates a TCPServer socket within ruby, then passes an fd
> representing that socket to libev--I'm not sure why but running the
> ioctlsocket test on it returns -1 with wsagetlasterror 10038
> Odd. I'm pretty sure it's creating the sockets deep within ruby with
> 'socket' or WSASocket or the like. Ruby can select on them just fine.
> Thanks for your time.
More information about the libev