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
aconfigure 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)
somethingelse 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