Re: Windows + IP6 progress - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Windows + IP6 progress
Date
Msg-id 4305CED9.6090902@dunslane.net
Whole thread Raw
In response to Re: Windows + IP6 progress  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

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



pgsql-hackers by date:

Previous
From: Tommi Maekitalo
Date:
Subject: Re: Windows + IP6 progress
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Cascades Failing