> From: Gisle Vanem
> 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,
On Monday 11 April 2016 11:30:45 Gisle Vanem wrote:
> 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
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()
> From: Tim Rühsen
> Date: Sun, 10 Apr 2016 20:29:36 +0200
>
> > I have tried building latest Wget with '-DHAVE_LIBCARES'
> > and all resolve attempts failed due to Gnulib's select()
> > is not compatible with the socket-number(s) returned from
> > a normal C-ares library on
Hi Gisle,
thanks for the fix.
Am Samstag, 9. April 2016, 21:58:18 schrieb Gisle Vanem:
> I have tried building latest Wget with '-DHAVE_LIBCARES'
> and all resolve attempts failed due to Gnulib's select()
> is not compatible with the socket-number(s) returned from
> a normal C-ares library on
> From: Gisle Vanem
> Date: Sat, 9 Apr 2016 21:58:18 +0200
>
> I have tried building latest Wget with '-DHAVE_LIBCARES'
> and all resolve attempts failed due to Gnulib's select()
> is not compatible with the socket-number(s) returned from
> a normal C-ares library on Windows.
I have tried building latest Wget with '-DHAVE_LIBCARES'
and all resolve attempts failed due to Gnulib's select()
is not compatible with the socket-number(s) returned from
a normal C-ares library on Windows.
This is what I did to fix it:
--- a/host.c 2016-04-09 17:45:44
+++ b/host.c 2016-04-09