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