Thread: HP-UX 11.31 Itanium2 64bit again
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.
--
H.Merijn Brand merijn@procura.nl (072) 567 13 51
PROCURA B.V. http://www.procura.nl KvK 37140650
Ban de e-mail disclaimers: http://tinyurl.com/kmne65
"H.Merijn Brand" <h.m.brand@procura.nl> writes:
> 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?
PG is tested on approximately that configuration, or was till recently:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=HEAD
(Doesn't look like buildfarm member anole has run on HEAD in a couple
of months --- EDB folk, can you unwedge that?) We don't test Perl
compatibility however.
Assuming that that error is originating in PG and not somewhere in DBI
or Perl, it must be coming from this bit in fe-connect.c:
if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
(char *) &optval, &optlen) == -1)
{
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not get socket error status: %s\n"),
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
goto error_return;
}
which makes me wonder if you're hitting some form of the problem described
here:
http://curl.haxx.se/mail/lib-2009-04/0287.html
We normally avoid that problem by defining _XOPEN_SOURCE_EXTENDED
(see src/template/hpux, though you should check your build log to
make sure that symbol actually got passed to cc). I wonder though
if the Perl environment is somehow causing the other getsockopt
prototype to be called. Are you *sure* it's a 64-bit Perl build?
Was Perl itself built with _XOPEN_SOURCE_EXTENDED?
> 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.
AFAIK our code in this area has been about the same since well before 8.4,
so maybe what you're hitting is something else. But that's the only lead
I have on the basis of the offered evidence.
BTW, googling also turned up your old message
http://www.postgresql.org/message-id/20101216174803.20b2b6db@pc09.procura.nl
in which you claim to have changed the platform #define's around. That
may not have been such a great idea. We expect getsockopt to use the
same last argument type as accept() does, and if I've got all the details
straight, you need _XOPEN_SOURCE_EXTENDED to make that true on HPUX.
regards, tom lane
"H.Merijn Brand" <h.m.brand@procura.nl> writes:
> On Tue, 11 Mar 2014 11:38:40 -0400, Tom Lane <tgl@sss.pgh.pa.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
I do not know what is common on this mailing list: reply-all or only to
the list. Sorry if I break with common practice when I now do a
reply-all
On Tue, 11 Mar 2014 11:38:40 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hi Tom, thanks for replying, you are the same that tried to get me
forward last time.
> "H.Merijn Brand" <h.m.brand@procura.nl> writes:
> > 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?
>
> PG is tested on approximately that configuration, or was till recently:
> http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=HEAD
> (Doesn't look like buildfarm member anole has run on HEAD in a couple
> of months --- EDB folk, can you unwedge that?) We don't test Perl
> compatibility however.
>
> Assuming that that error is originating in PG and not somewhere in DBI
> or Perl, it must be coming from this bit in fe-connect.c:
>
> if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
> (char *) &optval, &optlen) == -1)
> {
> appendPQExpBuffer(&conn->errorMessage,
> libpq_gettext("could not get socket error status: %s\n"),
> SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
> goto error_return;
> }
>
> which makes me wonder if you're hitting some form of the problem described
> here: http://curl.haxx.se/mail/lib-2009-04/0287.html
>
> We normally avoid that problem by defining _XOPEN_SOURCE_EXTENDED
> (see src/template/hpux, though you should check your build log to
> make sure that symbol actually got passed to cc). I wonder though
> if the Perl environment is somehow causing the other getsockopt
> prototype to be called. Are you *sure* it's a 64-bit Perl build?
Yes:
$ file `which perl`
/pro/bin/perl: ELF-64 executable object file - IA64
> Was Perl itself built with _XOPEN_SOURCE_EXTENDED?
No:
$ perl -V:.* | grep Ae
ccflags=' -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include
-D_LARGEFILE_SOURCE-D_FILE_OFFSET_BITS=64 ';
cppflags='-Aa -D__STDC_EXT__ -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Ae -DPERL_DONT_CREATE_GVSV +Z -z
-D_HPUX_SOURCE-Wl,+vnocompatwarnings +DD64 -I/pro/local/include';
ccflags_nolargefiles=' -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64
-I/pro/local/include ';
> > 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.
>
> AFAIK our code in this area has been about the same since well before 8.4,
> so maybe what you're hitting is something else. But that's the only lead
> I have on the basis of the offered evidence.
>
> BTW, googling also turned up your old message
> http://www.postgresql.org/message-id/20101216174803.20b2b6db@pc09.procura.nl
> in which you claim to have changed the platform #define's around. That
> may not have been such a great idea. We expect getsockopt to use the
> same last argument type as accept() does, and if I've got all the details
> straight, you need _XOPEN_SOURCE_EXTENDED to make that true on HPUX.
This time, postgres built out-of-the-box for both HP C-ANSI-C and
GNU-gcc, so I did not have to change any defines! :)
And I also have those mails stored and reread them, but the only thing
alike is the socket fail. I did not get any of the build failures
> regards, tom lane
--
H.Merijn Brand merijn@procura.nl (072) 567 13 51
PROCURA B.V. http://www.procura.nl KvK 37140650
Ban de e-mail disclaimers: http://tinyurl.com/kmne65
On Tue, 11 Mar 2014 11:38:40 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote: > We normally avoid that problem by defining _XOPEN_SOURCE_EXTENDED > (see src/template/hpux, though you should check your build log to > make sure that symbol actually got passed to cc). I wonder though > if the Perl environment is somehow causing the other getsockopt > prototype to be called. Are you *sure* it's a 64-bit Perl build? > 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. So I might be warnocked here. Rebuilding perl from scratch is - right now - not an option. I'll check if adding it will build perl at all (and still pass all tests). If so, the next thing would be to check if Oracle still works with *that* perl. If it doesn't even rebuilding perl and all modules is not an option. -- H.Merijn Brand merijn@procura.nl (072) 567 13 51 PROCURA B.V. http://www.procura.nl KvK 37140650 Ban de e-mail disclaimers: http://tinyurl.com/kmne65
I'm taking a look.. Results for all branches should be available soon..
On Tue, Mar 11, 2014 at 9:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "H.Merijn Brand" <h.m.brand@procura.nl> writes:
> > 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?
>
> PG is tested on approximately that configuration, or was till recently:
> http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=HEAD
> (Doesn't look like buildfarm member anole has run on HEAD in a couple
> of months --- EDB folk, can you unwedge that?) We don't test Perl
> compatibility however.
>
> Assuming that that error is originating in PG and not somewhere in DBI
> or Perl, it must be coming from this bit in fe-connect.c:
>
> if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
> (char *) &optval, &optlen) == -1)
> {
> appendPQExpBuffer(&conn->errorMessage,
> libpq_gettext("could not get socket error status:
> %s\n"),
> SOCK_STRERROR(SOCK_ERRNO, sebuf,
> sizeof(sebuf)));
> goto error_return;
> }
>
> which makes me wonder if you're hitting some form of the problem described
> here:
> http://curl.haxx.se/mail/lib-2009-04/0287.html
>
> We normally avoid that problem by defining _XOPEN_SOURCE_EXTENDED
> (see src/template/hpux, though you should check your build log to
> make sure that symbol actually got passed to cc). I wonder though
> if the Perl environment is somehow causing the other getsockopt
> prototype to be called. Are you *sure* it's a 64-bit Perl build?
> Was Perl itself built with _XOPEN_SOURCE_EXTENDED?
>
> > 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.
>
> AFAIK our code in this area has been about the same since well before 8.4,
> so maybe what you're hitting is something else. But that's the only lead
> I have on the basis of the offered evidence.
>
> BTW, googling also turned up your old message
>
> http://www.postgresql.org/message-id/20101216174803.20b2b6db@pc09.procura.nl
> in which you claim to have changed the platform #define's around. That
> may not have been such a great idea. We expect getsockopt to use the
> same last argument type as accept() does, and if I've got all the details
> straight, you need _XOPEN_SOURCE_EXTENDED to make that true on HPUX.
>
> regards, tom lane
>
--
Sandeep Thakkar
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs