Re: [Fwd: DBD::Pg on HP-UX 11.31 64bit] - Mailing list pgsql-bugs

"H.Merijn Brand" <h.m.brand@xs4all.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-branchrevision 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