From: | Shawn Doyle <sdoyle0(at)gmail(dot)com> |
---|---|
To: | "H(dot)Merijn Brand" <h(dot)m(dot)brand(at)procura(dot)nl>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: HP-UX 11.31 Itanium2 64bit again |
Date: | 2017-06-03 02:40:13 |
Message-ID: | 50aee370-14df-6dd4-782e-05589898f36e@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 3/11/2014 8:32 AM, H.Merijn Brand wrote:
> Back in December 2010 I reported to be unable to *use* a postgres build
> on HP-UX 11.31 (64bit). The configure/build/test works fine for both HP
> C-ANSI-C ( HP C/aC++ B3910B A.06.26 [Apr 12 2011]) or gcc-4.7.2 and for
> both the product works fine on itself after installation.
>
> That however is somewhat useless, as the database is running on another
> machine and I only need the installed postgres for its shared libraries
> to link against perl for DBD::Pg. (having psql locally is a pre, but it
> is not a necessity)
>
> The available perl is a 64bit build, so my postgresql libraries have to
> be 64bit too. As I only have 64bit versions of openssl, that all makes
> sense for both postgresql and perl anyway. Another reason perl is built
> in 64bit is that I only have 64bit Oracle libs and perl scripts have to
> connect to both Oracle and PostgreSQL simultaneously.
>
> 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?
>
> 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.
>
> I found myself in exactly the same state as in 2010/2011.
>
Not sure if this is still an outstanding issue, but I was trying to do
the same thing and ran into the same issue this week and after much
digging, finally managed to find a solution, so wanted to follow up for
anyone else who may come across this. There are basically two options:
1) Build the tool connecting (unixODBC in my case) to the HPUX
PostgreSQL server with LDFLAGS="-lxnet"
2) Build the PostgreSQL server with these additional parameters for
CFLAGS (in addition to existing flags you're using):
"-D_XOPEN_SOURCE=600 -D_HPUX_ALT_XOPEN_SOCKET_API"
A detailed explanation can be found at
https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html,
but basically PostgreSQL by default is compiled with the xnet library.
Option 1 above includes the xnet library in the connecting tool so it
has the same Socket styles. Option 2 above builds the PostgreSQL server
with support for both socket function styles.
Hope this helps,
Shawn Doyle
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-03 02:43:35 | Re: BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompression assumption, defaults to SSL_OP_NO_COMPRESSION |
Previous Message | greenreaper | 2017-06-03 02:05:54 | BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompression assumption, defaults to SSL_OP_NO_COMPRESSION |