Re: HP-UX 11.31 Itanium2 64bit again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "H(dot)Merijn Brand" <h(dot)m(dot)brand(at)procura(dot)nl>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: HP-UX 11.31 Itanium2 64bit again
Date: 2014-03-11 18:09:10
Message-ID: 17092.1394561350@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"H.Merijn Brand" <h(dot)m(dot)brand(at)procura(dot)nl> writes:
> On Tue, 11 Mar 2014 11:38:40 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Was Perl itself built with _XOPEN_SOURCE_EXTENDED?

> Just to make sure, building postgres with that define removed does NOT
> make it pass the tests.

I wouldn't expect it to. You'd at least have to go around and change all
the getsockopt calls to pass integer rather than ACCEPT_TYPE_ARG3 last
arguments. Possibly setsockopt and some other calls would be affected
too; I don't have the means or desire to research that myself.

It's not really clear that this is the source of the issue, though.
For it to be that, the surrounding Perl executable would have to be
determining which flavor of getsockopt() libpq.so is getting linked to.
I don't know what method HPUX11 uses to control that, but on systems
that I *am* familiar with, it's done with a differently named link
symbol, so that no such bugs should arise.

Still, you could try hacking the one place in fe-connect.c and see
whether the Perl test gets any further; that would give some evidence
to tell whether it's worth trying to fix things enough to have a
completely working Postgres build without _XOPEN_SOURCE_EXTENDED.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Lekshmi Ts 2014-03-12 04:50:35 postgres 8.2.13 compatibility with RHEL 6.4
Previous Message H.Merijn Brand 2014-03-11 16:49:22 Re: HP-UX 11.31 Itanium2 64bit again