Thread: Windows + IP6 progress
I have just managed to get pg server and client (cvs tip) talking IPv6 on Windows. :-) 1. Building - added in library in configure.in: AC_CHECK_LIB(ws2_32, main) - faked out getaddrinfo testin resulting configure and force answer to "yes" - added these lines to src/include/port/win32/sys/socket.h: #include <ws2tcpip.h> #define gai_strerrorA(err)"undetermined getaddrinfo error" After installation and initdb, I edited postgresql.conf to set listen_addresses to '127.0.0.1, ::1' just to make sure what we were getting. 2. Running without IPv6 driver installed. The build works, although it complains about IPv6 addresses. But I could run it with IPv4 addresses quite happily - the IPv6 addresses just fail, but they don't stop us running. 3. Running with IPv6 driver installed Now the build does not complain about IPv6 addresses (either in pg_hba.conf or postgresql.conf) And this command works: psql -h ::1 -l So the remaining questions are: . what do we do about the getaddrinfo test? I'm almost inclined not to do it on windows, and assume that if we have ws2_32.dll we have it. . what to do about the gai_strerror mess (import our own but leave out our own getaddrinfo?) . make sure that this doesn't break less modern Windows platforms than mine (XP Pro SP1). How ubiquitous is ws2_32.dll? I have asked a few people to test this build. I don't want to publish its location openly, but if anyone wants to help they can drop me an email. Alternatively, some kind person could provide a site on a nice fat pipe for an 18Mb download. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> . what do we do about the getaddrinfo test? I'm almost inclined not to
> do it on windows, and assume that if we have ws2_32.dll we have it.
There's something mighty fishy about that. AC_REPLACE_FUNCS works on
Windows for the other cases it's used for (no?), so what's different
about getaddrinfo? Perhaps Microsoft has #define'd that name as
something else, or some equally ugly crock? It'd be useful to look into
their header files and see exactly how and where getaddrinfo is
declared.
regards, tom lane
The definition in WS2tcpip.h WINSOCK_API_LINKAGE int WSAAPI getaddrinfo( IN const char FAR * nodename, IN const char FAR * servname, IN const struct addrinfo FAR * hints, OUTstruct addrinfo FAR * FAR * res ); (IN, FAR, and OUT are #defined to empty string). WINSOCK_API_LINKAGE is __declspec(dllimport) WSAAPI is __stdcall So, nothing magic with #defines of the name getaddrinfo. > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > owner@postgresql.org] On Behalf Of Tom Lane > Sent: Thursday, August 18, 2005 3:47 PM > To: Andrew Dunstan > Cc: PostgreSQL-development > Subject: Re: [HACKERS] Windows + IP6 progress > > Andrew Dunstan <andrew@dunslane.net> writes: > > . what do we do about the getaddrinfo test? I'm almost inclined not to > > do it on windows, and assume that if we have ws2_32.dll we have it. > > There's something mighty fishy about that. AC_REPLACE_FUNCS works on > Windows for the other cases it's used for (no?), so what's different > about getaddrinfo? Perhaps Microsoft has #define'd that name as > something else, or some equally ugly crock? It'd be useful to look into > their header files and see exactly how and where getaddrinfo is > declared. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq
IPv6 exists in a "production quality" state only in XP sp1, XP sp2, and
Windows 2003.
There was an optional prototype stack for 2000, but not production
quality and not installed by default. XP non-service-pack had IPv6,
but not production-quality.
One thing you could do is dynamically load getaddrinfo from ws2_32.dll
at run time. If the DLL doesn't exist, or getaddrinfo isn't in that
ws2_32.dll, you could then fail gracefully (somehow).
You call something like:
hWs2_32 = LoadLibraryA("ws2_32.dll");if (hWs2_32){ Getaddrinfoptr = GetProcAddress(hWs2_32, "getaddrinfo");}
The GetProcAddress will return null if getaddrinfo doesn't exist, and a
pointer to the routine if it does.
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Andrew Dunstan
> Sent: Thursday, August 18, 2005 3:17 PM
> To: PostgreSQL-development
> Subject: [HACKERS] Windows + IP6 progress
>
>
> I have just managed to get pg server and client (cvs tip) talking IPv6
> on Windows. :-)
>
> 1. Building
> - added in library in configure.in:
> AC_CHECK_LIB(ws2_32, main)
> - faked out getaddrinfo test in resulting configure and force
answer
> to "yes"
> - added these lines to src/include/port/win32/sys/socket.h:
> #include <ws2tcpip.h>
> #define gai_strerrorA(err) "undetermined getaddrinfo error"
>
> After installation and initdb, I edited postgresql.conf to set
> listen_addresses to '127.0.0.1, ::1' just to make sure what we were
> getting.
>
> 2. Running without IPv6 driver installed.
> The build works, although it complains about IPv6 addresses. But I
> could run it with IPv4 addresses quite happily - the IPv6 addresses
just
> fail, but they don't stop us running.
>
> 3. Running with IPv6 driver installed
> Now the build does not complain about IPv6 addresses (either in
> pg_hba.conf or postgresql.conf)
> And this command works: psql -h ::1 -l
>
>
> So the remaining questions are:
> . what do we do about the getaddrinfo test? I'm almost inclined not to
> do it on windows, and assume that if we have ws2_32.dll we have it.
> . what to do about the gai_strerror mess (import our own but leave out
> our own getaddrinfo?)
> . make sure that this doesn't break less modern Windows platforms than
> mine (XP Pro SP1). How ubiquitous is ws2_32.dll?
>
> I have asked a few people to test this build. I don't want to publish
> its location openly, but if anyone wants to help they can drop me an
> email. Alternatively, some kind person could provide a site on a nice
> fat pipe for an 18Mb download.
>
>
> cheers
>
> andrew
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 6: explain analyze is your friend
The mingw header has pretty much this with WINSOCK_API_LINKAGE IN OUT and FAR dissolved away. The standard test complains about it being an unresolved reference when it is declared as "char getaddrinfo (); ". If we remove that and instead include the header the test passes. I have no idea why that should be the case for this function and not for others. cheers andrew Chuck McDevitt wrote: >The definition in WS2tcpip.h > >WINSOCK_API_LINKAGE >int >WSAAPI >getaddrinfo( > IN const char FAR * nodename, > IN const char FAR * servname, > IN const struct addrinfo FAR * hints, > OUT struct addrinfo FAR * FAR * res > ); > > >(IN, FAR, and OUT are #defined to empty string). > >WINSOCK_API_LINKAGE is __declspec(dllimport) >WSAAPI is __stdcall > >So, nothing magic with #defines of the name getaddrinfo. > > > > >>-----Original Message----- >>From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- >>owner@postgresql.org] On Behalf Of Tom Lane >>Sent: Thursday, August 18, 2005 3:47 PM >>To: Andrew Dunstan >>Cc: PostgreSQL-development >>Subject: Re: [HACKERS] Windows + IP6 progress >> >>Andrew Dunstan <andrew@dunslane.net> writes: >> >> >>>. what do we do about the getaddrinfo test? I'm almost inclined not >>> >>> >to > > >>>do it on windows, and assume that if we have ws2_32.dll we have it. >>> >>> >>There's something mighty fishy about that. AC_REPLACE_FUNCS works on >>Windows for the other cases it's used for (no?), so what's different >>about getaddrinfo? Perhaps Microsoft has #define'd that name as >>something else, or some equally ugly crock? It'd be useful to look >> >> >into > > >>their header files and see exactly how and where getaddrinfo is >>declared. >> >> regards, tom lane >> >>---------------------------(end of >> >> >broadcast)--------------------------- > > >>TIP 3: Have you checked our extensive FAQ? >> >> http://www.postgresql.org/docs/faq >> >> > > > >
I think it's because it's __stdcall, and the name gets mangled to include the number of parameters. > -----Original Message----- > From: Andrew Dunstan [mailto:andrew@dunslane.net] > Sent: Thursday, August 18, 2005 4:44 PM > To: Chuck McDevitt > Cc: Tom Lane; PostgreSQL-development > Subject: Re: [HACKERS] Windows + IP6 progress > > > The mingw header has pretty much this with WINSOCK_API_LINKAGE IN OUT > and FAR dissolved away. > > The standard test complains about it being an unresolved reference when > it is declared as "char getaddrinfo (); ". If we remove that and instead > include the header the test passes. I have no idea why that should be > the case for this function and not for others. > > cheers > > andrew > > > Chuck McDevitt wrote: > > >The definition in WS2tcpip.h > > > >WINSOCK_API_LINKAGE > >int > >WSAAPI > >getaddrinfo( > > IN const char FAR * nodename, > > IN const char FAR * servname, > > IN const struct addrinfo FAR * hints, > > OUT struct addrinfo FAR * FAR * res > > ); > > > > > >(IN, FAR, and OUT are #defined to empty string). > > > >WINSOCK_API_LINKAGE is __declspec(dllimport) > >WSAAPI is __stdcall > > > >So, nothing magic with #defines of the name getaddrinfo. > > > > > > > > > >>-----Original Message----- > >>From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > >>owner@postgresql.org] On Behalf Of Tom Lane > >>Sent: Thursday, August 18, 2005 3:47 PM > >>To: Andrew Dunstan > >>Cc: PostgreSQL-development > >>Subject: Re: [HACKERS] Windows + IP6 progress > >> > >>Andrew Dunstan <andrew@dunslane.net> writes: > >> > >> > >>>. what do we do about the getaddrinfo test? I'm almost inclined not > >>> > >>> > >to > > > > > >>>do it on windows, and assume that if we have ws2_32.dll we have it. > >>> > >>> > >>There's something mighty fishy about that. AC_REPLACE_FUNCS works on > >>Windows for the other cases it's used for (no?), so what's different > >>about getaddrinfo? Perhaps Microsoft has #define'd that name as > >>something else, or some equally ugly crock? It'd be useful to look > >> > >> > >into > > > > > >>their header files and see exactly how and where getaddrinfo is > >>declared. > >> > >> regards, tom lane > >> > >>---------------------------(end of > >> > >> > >broadcast)--------------------------- > > > > > >>TIP 3: Have you checked our extensive FAQ? > >> > >> http://www.postgresql.org/docs/faq > >> > >> > > > > > > > >
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? cheers andrew
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?
regards, tom lane
Hi, I don't have win32-headers here, but as far as I remember the headers (re-)#define many calls. getaddrinfo might be getaddrinfoA or something. When you don't use the headers and try to link with the name getaddrinfo, it is not found. The options are either look, what name is actually used for linking and test against this name (as an alternative of course) or include the needed header. Tommi Am Freitag, 19. August 2005 01:44 schrieb Andrew Dunstan: > The mingw header has pretty much this with WINSOCK_API_LINKAGE IN OUT > and FAR dissolved away. > > The standard test complains about it being an unresolved reference when > it is declared as "char getaddrinfo (); ". If we remove that and instead > include the header the test passes. I have no idea why that should be > the case for this function and not for others. > > cheers > > andrew > > Chuck McDevitt wrote: > >The definition in WS2tcpip.h > > > >WINSOCK_API_LINKAGE > >int > >WSAAPI > >getaddrinfo( > > IN const char FAR * nodename, > > IN const char FAR * servname, > > IN const struct addrinfo FAR * hints, > > OUT struct addrinfo FAR * FAR * res > > ); > > > > > >(IN, FAR, and OUT are #defined to empty string). > > > >WINSOCK_API_LINKAGE is __declspec(dllimport) > >WSAAPI is __stdcall > > > >So, nothing magic with #defines of the name getaddrinfo. > > > >>-----Original Message----- > >>From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > >>owner@postgresql.org] On Behalf Of Tom Lane > >>Sent: Thursday, August 18, 2005 3:47 PM > >>To: Andrew Dunstan > >>Cc: PostgreSQL-development > >>Subject: Re: [HACKERS] Windows + IP6 progress > >> > >>Andrew Dunstan <andrew@dunslane.net> writes: > >>>. what do we do about the getaddrinfo test? I'm almost inclined not > > > >to > > > >>>do it on windows, and assume that if we have ws2_32.dll we have it. > >> > >>There's something mighty fishy about that. AC_REPLACE_FUNCS works on > >>Windows for the other cases it's used for (no?), so what's different > >>about getaddrinfo? Perhaps Microsoft has #define'd that name as > >>something else, or some equally ugly crock? It'd be useful to look > > > >into > > > >>their header files and see exactly how and where getaddrinfo is > >>declared. > >> > >> regards, tom lane > >> > >>---------------------------(end of > > > >broadcast)--------------------------- > > > >>TIP 3: Have you checked our extensive FAQ? > >> > >> http://www.postgresql.org/docs/faq > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Mit freundlichen Grüßen Tommi Mäkitalo Dr. Eckhardt + Partner GmbH
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
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 >