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

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

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

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:

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

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 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

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