The advantage of doing the check at run-time is that you can build
PostgreSQL on one machine (which has IPv6), and have it run on some
other windows box (which might not have IPv6). So you'd only need one
set of binaries.
Routines like "getopt" are not __stdcall, so their names don't get
mangled. Only actual calls to the Win32 API would likely be __stdcall.
> -----Original Message-----
> From: Andrew Dunstan [mailto:andrew@dunslane.net]
> Sent: Friday, August 19, 2005 5:22 AM
> To: Tom Lane
> Cc: Chuck McDevitt; PostgreSQL-development
> Subject: Re: [HACKERS] Windows + IP6 progress
>
>
>
> Tom Lane wrote:
>
> >Andrew Dunstan <andrew@dunslane.net> writes:
> >
> >
> >>Chuck McDevitt wrote:
> >>
> >>
> >>>I think it's because it's __stdcall, and the name gets mangled to
> >>>include the number of parameters.
> >>>
> >>>
> >
> >
> >
> >>Aha! now it makes sense. How do we get around that in the configure
> tests?
> >>
> >>
> >
> >I thought it might be something like that ... but the question
remains:
> >how/why is getaddrinfo different from all the other library routines
we
> >probe for?
> >
> >
> >
> >
>
> I think many if not all of those that succeed come from the mingw
> libraries. For example, the Windows libraries don't have getopt at
all,
> I believe.
>
> But I confess I don't understand enough about how it works to give a
> definitive answer.
>
> Meanwhile, Petr Jelinek reports that the binaries I made fail on
Windows
> versions as modern as Windows 2000 (missing freeaddrinfo). Darn.
>
> So the choices appear to be:
> a) check for all the required functions at runtime, and otherwise
use
> our homegrown getaddrinfo and friends (and don't support ipv6)
> b) teach our getaddrinfo and friends about ipv6
> c) have a configure flag (--enable-win-ipv6 ? ) for those Windows
> platforms that do/don't support ipv6. That would mean 2 sets of
> binaries ;-(
> d) don't support ipv6 in windows.
> e) something else I haven't thought of
>
> Looks to me like a) is the best bet, but it's beyond my Windows
> programming capacity and experience. We do something of the sort with
> src/interfaces/libpq/win32.c. Maybe Chuck or Petr could come up with a
> patch?
>
> cheers
>
> andrew
>