[PORTS] Libpq visual c++ build errors, addrinfo and

[Magnus Hagander]

hi,
While trying to update the PHP postgresql extension to 8.3.1, I met a
couple of issues.
The first was about not using kerberos, the makefile is incorrect as
an error will be raised when kerberos is used and no kerberos is used.

First of all, what version of MSVC are you building this with? And what
version of the Platform SDK?

Second, is there any particular reason you need to build it yourself,
instead of using the binaries that we ship already?

And third, I'd recommend you try to build it using the "main method"
which is using the tools in src/tools/msvc, and not the win32.mak
method. It's much more complete. You can build "just libpq" that way as
well.

The 2nd problem is about Shell32.lib, it is missing in the lib list.
It is required for SHGetFolderPath.

That's strange, because if that was so then nobody should be able to
build it. We should be getting the symbol from shfolder.lib.

The last two problems are more tricky. It is about addrinfo and
sockaddr. addrinfo is actually defined on windows and seems to have
the correct order of the structure elements (see the comment in
src/include/getaddrinfo.h). Removing this declaration seems to work
(not tested yet).

Again, you seem to be doing *something* wrong here, because it builds
perfectly fine for others. :-) Anything "unusual" about your
environment, that you would guess?

(And do try the "real" backend build way instead of win32.mak. Even if
it doesn't fix your issue, it might help with showing us what actually
is wrong)

//Magnus

[Magnus Hagander]

Hi Magnus,

Post by Magnus Hagander

hi,
While trying to update the PHP postgresql extension to 8.3.1, I
met a couple of issues.
The first was about not using kerberos, the makefile is
incorrect as an error will be raised when kerberos is used and
no kerberos is used.

First of all, what version of MSVC are you building this with? And
what version of the Platform SDK?

We use the last SDK working with VC6 (2003/02). That's sadly a
requirement for php 5.x. We are working on supporting 2k5 and the
latest SDK for 5.3+. However VC6 support has to be kept for the 5.x
branches (at least).

There's your problem, really. 8.3+ does not support VC6 anymore. We
need 7.1 or newer.

Post by Magnus Hagander
And third, I'd recommend you try to build it using the "main
method" which is using the tools in src/tools/msvc, and not the
win32.mak method. It's much more complete. You can build "just
libpq" that way as well.

I did not know this one, thanks! I will give it tonight.

That one will require Visual Studio 2005...

Post by Magnus Hagander

The last two problems are more tricky. It is about addrinfo and
sockaddr. addrinfo is actually defined on windows and seems to
have the correct order of the structure elements (see the
comment in src/include/getaddrinfo.h). Removing this declaration
seems to work (not tested yet).

Again, you seem to be doing *something* wrong here, because it
builds perfectly fine for others. :-) Anything "unusual" about your
environment, that you would guess?

Besides the museum piece of software that is the 2003's SDK,
nothing ;)

:-D


//Magnus

[Magnus Hagander]

Post by Magnus Hagander

We use the last SDK working with VC6 (2003/02). That's sadly a
requirement for php 5.x. We are working on supporting 2k5 and
the latest SDK for 5.3+. However VC6 support has to be kept for
the 5.x branches (at least).

There's your problem, really. 8.3+ does not support VC6 anymore. We
need 7.1 or newer.

I was suspecting this problem. Do you have any experiences of using
these 2k5 binaries with VC6 (especially in threaded environment)? We
may give it a try in the next weeks and update it again in 5.2.7 and
5.3 if it works well.

It shouldn't be a problem, other than requiring both runtimes to be
present. Unless you use PQtrace() in which case it will be a big
problem.

Basically, as long as you don't free() something in one runtime that
was malloced():d in a nother one, and as long as you don't pass "CRT
pointers" between the two runtimes, you are fine. And we do pass a CRT
pointer around in PQtrace, but that's the only case. We used to have a
problem with some Kerberos structure that was malloced in one place and
free()d in another, but that has been fixed.

//Magnus