Re: HP-UX 11.31 Itanium2 64bit again

I do not know what is common on this mailing list: reply-all or only to
the list. Sorry if I break with common practice when I now do a
reply-all

On Tue, 11 Mar 2014 11:38:40 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

Hi Tom, thanks for replying, you are the same that tried to get me
forward last time.

> "H.Merijn Brand" <h(dot)m(dot)brand(at)procura(dot)nl> writes:
> > After the installation, DBD::Pg is able to link against libpq.so.5, but
> > just as in 2010/2011, it is not able to make any connection due to some
> > socket incompatabilities:
>
> > $ perl -MDBI -wE'DBI->connect ("dbi:Pg:")'
> > DBI connect('','',...) failed: could not get socket error status: Invalid argument at -e line 1.
>
> > The docs state that HP-UX is one of the platforms postgresql is tested
> > on, but is it ever tested beyond the product itself? Is there anyone to
> > guide me in making this work?
>
> PG is tested on approximately that configuration, or was till recently:
> http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=HEAD
> (Doesn't look like buildfarm member anole has run on HEAD in a couple
> of months --- EDB folk, can you unwedge that?) We don't test Perl
> compatibility however.
>
> Assuming that that error is originating in PG and not somewhere in DBI
> or Perl, it must be coming from this bit in fe-connect.c:
>
> if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
> (char *) &optval, &optlen) == -1)
> {
> appendPQExpBuffer(&conn->errorMessage,
> libpq_gettext("could not get socket error status: %s\n"),
> SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
> goto error_return;
> }
>
> which makes me wonder if you're hitting some form of the problem described
> here: http://curl.haxx.se/mail/lib-2009-04/0287.html
>
> We normally avoid that problem by defining _XOPEN_SOURCE_EXTENDED
> (see src/template/hpux, though you should check your build log to
> make sure that symbol actually got passed to cc). I wonder though
> if the Perl environment is somehow causing the other getsockopt
> prototype to be called. Are you *sure* it's a 64-bit Perl build?

Yes:

$ file `which perl`
/pro/bin/perl: ELF-64 executable object file - IA64

> Was Perl itself built with _XOPEN_SOURCE_EXTENDED?

No:

$ perl -V:.* | grep Ae
ccflags=' -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ';
cppflags='-Aa -D__STDC_EXT__ -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include';
ccflags_nolargefiles=' -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include ';

> > I am now stuck to postgresql-8.4.5 which is the last release I was able
> > to build to a state that worked with perl.
>
> AFAIK our code in this area has been about the same since well before 8.4,
> so maybe what you're hitting is something else. But that's the only lead
> I have on the basis of the offered evidence.
>
> BTW, googling also turned up your old message
> http://www.postgresql.org/message-id/20101216174803.20b2b6db@pc09.procura.nl
> in which you claim to have changed the platform #define's around. That
> may not have been such a great idea. We expect getsockopt to use the
> same last argument type as accept() does, and if I've got all the details
> straight, you need _XOPEN_SOURCE_EXTENDED to make that true on HPUX.

This time, postgres built out-of-the-box for both HP C-ANSI-C and
GNU-gcc, so I did not have to change any defines! :)

And I also have those mails stored and reread them, but the only thing
alike is the socket fail. I did not get any of the build failures

> regards, tom lane

--
H.Merijn Brand merijn(at)procura(dot)nl (072) 567 13 51
PROCURA B.V. http://www.procura.nl KvK 37140650
Ban de e-mail disclaimers: http://tinyurl.com/kmne65