Re: Libpq visual c++ build errors, addrinfo and sockaddr_storage redefinition error

Hi Magnus,

On Tue, May 6, 2008 at 1:36 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Pierre Joye wrote:
> > 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).

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

Mainly because of VC6, we had many issues in the pasts with builds not
using the exact same crt than PHP.

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

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

I got an unknown symbol "SHGetFolderPath" using win32.mak.

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

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

Yes, I will definitively try the "normal" way. It will certainly fix
all the issues. I'll come back to you after my tests.

Thanks for your quick reply and the tips!

--
Pierre

http://blog.thepimp.net | http://www.libgd.org