> From: Gisle Vanem <[email protected]> > Date: Mon, 11 Apr 2016 11:30:45 +0200 > > Tim Rühsen wrote: > > > As Eli, I would like to know a few more details. > > Is it possible to make c-ares return the 'native' socket numbers to not get > > in > > conflict with gnulib ? > > As Eli pointed out, it's vice-versa; C-ares *do* return 'native' > socket numbers. While Gnulib's socket(), select() etc. creates and > expects 'file descriptors'. Normally in the range >= 3 (?). (I assume > this has something to POSIX compliance. Winsock's socket() never returns > such low numbers).
Windows sockets are handles in disguise, not file descriptors. > Eli> However, converting a handle into a > Eli> file descriptor and vise versa involves using 2 simple functions, > > I'm not sure what those functions are since I'm not so much into Gnulib. It's not a Gnulib thing, it's a Windows runtime library thing: HANDLE h = _get_osfhandle (int fd); will produce a handle underlying a file descriptor, while int fd = _open_osfhandle (HANDLE h, O_RDWR | O_BINARY); will do the opposite. > My intuition told me the 'rpl_select()' was the cause for the resolve- > failure, hence this 'undef'. And since the host.c 'select()' is used only for > 'HAVE_LIBCARES' code, I felt it won't hurt do '#undef select' in host.c. Is it a good idea to have 2 different implementations of 'select' in the same program? Can it happen that Wget wants to wait on both the libcares sockets and the other kind? > But I'm open to alternatives. Eli, can you try building with > 'HAVE_LIBCARES'? Not right now, as I'm quite busy these days.
