Re: [Fwd: DBD::Pg on HP-UX 11.31 64bit]

"H.Merijn Brand" <h(dot)m(dot)brand(at)xs4all(dot)nl> writes:
> This is what the docs on HP-UX say:

> int getsockopt (
> int s,
> int level,
> int optname,
> void *optval,
> int *optlen
> );

> UNIX 03 Only (X/Open Sockets)

> int getsockopt (
> int s,
> int level,
> int optname,
> void *__restrict optval,
> socklen_t *__restrict optlen
> );

Mmm, fun. And what is socklen_t defined as?

> the includes tell me
> src/include/pg_config.h:#define ACCEPT_TYPE_ARG3 size_t

Hmm, that suggests that configure was already seeing the socklen_t
variant ...

> To use X/Open sockets, which seems to me the better option for
> postgresql, I changed scr/Makefile.global =>

> CC = cc
> CFLAGS = -O2 -g -Ae -z +Z +DD64 -D_XOPEN_SOURCE=600
> LIBS = -lssl -lcrypto -lxnet -lz -lm
> LDFLAGS = -Wl,+vnocompatwarnings +DD64 -L/usr/local/ia64/lib \
> -L/usr/lib/hpux64 -L/usr/contrib/X11R6/lib/hpux64 -s \
> -L/usr/local/lib -L/usr/lib/X11R6 -L/usr/contrib/X11R6/lib

Screwing around with CFLAGS in an already-generated Makefile.global
is definitely *not* the way to approach this; you need configure to
have seen the same switches, else it will have selected the wrong
ACCEPT_TYPE_ARG3. Try it with
configure CPPFLAGS="-D_XOPEN_SOURCE=600"
or something like that.

> To ensure optimal alignment, I also added
> #pragma pack 16
> to all header files

And please do not inject random other ways of breaking things at the
same time --- there's no good reason to believe that that will even
work, and it's surely complicating trying to solve the immediate
problem.

> # PostgreSQL (reported) PostgreSQL 8.4.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839], 64-bit

Where'd that come from? Seems a bit weird that this is referring to
something other than your HPUX build.

> As, at this point, there is no control over the library that perl itself is linked with:

Hmm. I wonder whether perl is built with libraries that expect the
"int" definition instead of the "socklen_t" definition, or vice versa
(whichever way is not what libpq expects). Do you know exactly how HP
is managing to support both of those ABIs?

regards, tom lane