Re: [HACKERS] PostgreSQL X/Open Socket / BSD Socket Issue on HP-UX
On 22.09.2011 13:51, MUHAMMAD ASIF wrote:
You are right, _xpg_ socket functionality is not available in older systems, it
is available in hp-ux 11.23 version through patch HCO_35744 . HPUX 10.20 is
very old machine (1996). I am using latest HPUX B.11.31 machine, I don't have
access to older systems. -D_XOPEN_SOURCE_EXTENDED make the postgres build
X/Open Socket enabled including connector's i.e libpq. Now if system default
64bit perl (BSD Socket) try to use libpq (X/Open Socket) it will end up in
unexpected results or errors . HP-UX don't allow mixing of X/Open Socket
objects and BSD Socket objects in the same 64bit binary, HP tried to fix this
issue through -D_HPUX_ALT_XOPEN_SOCKET_API on later version of OS. It seems
nice that if postgres adopt this fix at least for connectors (PFA patch, minor
change in src/interfaces/libpq/Makefile) and so that users on later hp-ux boxes
don't trouble with these socket issues and connect their applications to
database server with the help of libpq without the fear of X/Open So
cket or BSD Socket complexity. On older system defining
_HPUX_ALT_XOPEN_SOCKET_API should do no effects or issues.
You're right that defining _HPUX_ALT_XOPEN_SOCKET_API should have no
effect on older systems that don't have that. But removing -lxnet and
-D_XOPEN_SOURCE_EXTENDED *is* clearly going to cause problems on older
systems.
According to
http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html,
-D_XOPEN_SOURCE_EXTENDED should still be defined, even if you use
-D_HPUX_ALT_XOPEN_SOCKET_API. So removing that was bogus. But -lxnet
should indeed not be used with _HPUX_ALT_XOPEN_SOCKET_API, so I think we
need a configure test to see whether that option is available, and use
it only if it is.
Looking at the headers, it seems pretty hard to detect whether
_HPUX_ALT_XOPEN_SOCKET_API is available. The best I can think of is to
check whether the _xpg_* functions exist. That's a bit ugly because a
program is not supposed to call those functions directly, but it should
work fine in practice, so attached is a patch to do that.
I did some experiments on my HP-UX box (HP-UX guest2 B.11.31 U ia64
HP-UX, according to uname -a). I built a small test program that uses
libpq, and also calls socket() and getsockopt() on an unrelated socket.
I also tested a little perl function in the database, that calls
getsockopt(). Without this patch, the perl function fails, and the test
program fails unless compiled with -lxnet -D_XOPEN_SOURCE_EXTENDED
(ie. unless it uses X/Open sockets). With the patch, the perl function
works, and the test program works, whether it's compiled with X/Open or not.
In the patch, I had to move the logic into configure.in, because the
autoconf AC_* macros can't be used in the template, which is a plain
shell script.
Unforunately I don't have access to any older HP-UX boxes that don't
have _HPUX_ALT_XOPEN_SOCKET_API. Tom, can you test this on that old
HP-UX box of yours?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/configure b/configure
index 58fea90..b209e0f 100755
--- a/configure
+++ b/configure
@@ -4654,6 +4654,131 @@ if test $PORTNAME = win32; then
CPPFLAGS=$CPPFLAGS -I$srcdir/src/include/port/win32 -DEXEC_BACKEND
fi
+# On HP-UX, we need to use the X/Open Networking Interfaces. Otherwise bind(),
+# getpeername() and so on don't work correctly in the LP64 data model.
+#
+# There are two ways to use X/Open Networking Interfaces, as described by
+# xopen_networking(7) man page. Method A is to define -D_XOPEN_SOURCE_EXTENDED
+# and link with -lxnet. libxnet contains the X/Open versions of the socket
+# functions. In method B, we define -D_XOPEN_SOURCE_EXTENDED and
+# _HPUX_ALT_XOPEN_SOCKET_API, and do *not* link with libxnet. In this method,
+# sys/socket.h maps the socket functions to variants in libc with prefix
+# _xpg_*, which have the right interface. Method B is preferred, as it allows
+# linking with other libraries whether they use BSD or X/Open sockets, but
+# it's not available on older versions of HP-UX. Detect whether method B can
+# be used, by checking whether libc has function _xpg_socket().
+if test $PORTNAME = hpux; then
+
+for ac_func in _xpg_socket
+do
+as_ac_var=`$as_echo ac_cv_func_$ac_func | $as_tr_sh`
+{ $as_echo $as_me:$LINENO: checking for $ac_func 5
+$as_echo_n checking for $ac_func... 6; }
+if { as_var=$as_ac_var; eval test \\${$as_var+set}\ = set; }; then
+ $as_echo_n (cached) 6
+else
+ cat conftest.$ac_ext _ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h conftest.$ac_ext
+cat conftest.$ac_ext _ACEOF
+/* end confdefs.h. */
+/* Define $ac_func to an innocuous variant, in case limits.h declares $ac_func.
+ For example, HP-UX 11i limits.h declares gettimeofday. */
+#define $ac_func innocuous_$ac_func
+
+/* System header to define __stub macros and hopefully few prototypes,
+which can conflict with char $ac_func (); below.
+Prefer
Re: [HACKERS] PostgreSQL X/Open Socket / BSD Socket Issue on HP-UX
Very sorry for late reply. You are right, _xpg_ socket functionality is not available in older systems, it is available in hp-ux 11.23 version through patch HCO_35744 . HPUX 10.20 is very old machine (1996). I am using latest HPUX B.11.31 machine, I don't have access to older systems. -D_XOPEN_SOURCE_EXTENDED make the postgres build X/Open Socket enabled including connector's i.e libpq. Now if system default 64bit perl (BSD Socket) try to use libpq (X/Open Socket) it will end up in unexpected results or errors . HP-UX don't allow mixing of X/Open Socket objects and BSD Socket objects in the same 64bit binary, HP tried to fix this issue through -D_HPUX_ALT_XOPEN_SOCKET_API on later version of OS. It seems nice that if postgres adopt this fix at least for connectors (PFA patch, minor change in src/interfaces/libpq/Makefile) and so that users on later hp-ux boxes don't trouble with these socket issues and connect their applications to database server with the help of libpq without the fear of X/Open Socket or BSD Socket complexity. On older system defining _HPUX_ALT_XOPEN_SOCKET_API should do no effects or issues. Thanks. ( http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html ).. HP-UX provides two styles of Sockets API: - default BSD Sockets -X/Open Sockets These two styles of Sockets API have the same function names but they have differences in semantics and argument types. For example, the optlen field in X/Open getsockopt() is size_t type, while BSD getsockopt() is int type. In 64 bit mode, size_t is 64 bit and int is still 32 bit. Linking objects compiled to X/Open Sockets specification and objects compiled to BSD Sockets specification in the same program using the linkage method in method A would erroneously resolve BSD Sockets calls to X/Open Sockets functions in the Xnet library. As a result, the program may result in application core dumps or unexpected Socket errors when it is run. These symptoms commonly occur when BSD Sockets accept(), getpeername(), getsockname(), getsockopt(), recvfrom(), sendmsg(), and recvmsg() are called. .. Best Regards,Muhammad Asif Naeem To: anaeem...@hotmail.com CC: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] PostgreSQL X/Open Socket / BSD Socket Issue on HP-UX Date: Tue, 20 Sep 2011 18:06:55 -0400 From: t...@sss.pgh.pa.us MUHAMMAD ASIF anaeem...@hotmail.com writes: I faced similar issue as discussed in http://postgresql.1045698.n5.nabble.com/Fwd-DBD-Pg-on-HP-UX-11-31-64bit-td3305163.html;. (man xopen_networking - http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html) ... There are two ways to obtain X/Open Sockets functionality: * Method A is in compliance with X/Open compilation specification.* Method B slightly deviates from X/Open compilation specification. However, Method B allows a program to include both objects compiled to X/Open Sockets specification and objects compiled to BSD Sockets specification. ... PostgreSQL support X/Open Sockets. Apache web server (2.2.15, /opt/hpws22/apache) and Perl (5.8.8, /opt/perl_64) are BSD Socket applications that are default with the OS. I tried Method B (It provides wrapper _xpg_ socket functions that allows using X/Open socket objects and BSD socket objects in the same binary) to build PostgreSQL 9.1 code, I LD_PRELOAD the generated libpq binary, without any other change both perl and apache work fine with postgresql now,and it is easy to implement too. We just need to build the source code with -D_XOPEN_SOURCE=600 -D_HPUX_ALT_XOPEN_SOCKET_API and link binary with libc. PFA patch. Thanks. AFAICT, the proposed patch will break things on at least some versions of HPUX. You can't just arbitrarily remove the reference to -lxnet, at least not without explaining to us why the existing comment about it is wrong. Likewise, removing -D_XOPEN_SOURCE_EXTENDED isn't acceptable without a whole more supporting evidence than you've provided. (I'm fairly certain that the latter will break the build on my old HPUX 10.20 box, for example.) regards, tom lane hp-ux_socket.patch.v2 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PostgreSQL X/Open Socket / BSD Socket Issue on HP-UX
Hi, I faced similar issue as discussed in http://postgresql.1045698.n5.nabble.com/Fwd-DBD-Pg-on-HP-UX-11-31-64bit-td3305163.html;. (man xopen_networking - http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html) ... There are two ways to obtain X/Open Sockets functionality: * Method A is in compliance with X/Open compilation specification. * Method B slightly deviates from X/Open compilation specification. However, Method B allows a program to include both objects compiled to X/Open Sockets specification and objects compiled to BSD Sockets specification. ... PostgreSQL support X/Open Sockets. Apache web server (2.2.15, /opt/hpws22/apache) and Perl (5.8.8, /opt/perl_64) are BSD Socket applications that are default with the OS. I tried Method B (It provides wrapper _xpg_ socket functions that allows using X/Open socket objects and BSD socket objects in the same binary) to build PostgreSQL 9.1 code, I LD_PRELOAD the generated libpq binary, without any other change both perl and apache work fine with postgresql now,and it is easy to implement too. We just need to build the source code with -D_XOPEN_SOURCE=600 -D_HPUX_ALT_XOPEN_SOCKET_API and link binary with libc. PFA patch. Thanks. Best Regards,Muhammad Asif Naeem hp-ux_socket.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL X/Open Socket / BSD Socket Issue on HP-UX
MUHAMMAD ASIF anaeem...@hotmail.com writes: I faced similar issue as discussed in http://postgresql.1045698.n5.nabble.com/Fwd-DBD-Pg-on-HP-UX-11-31-64bit-td3305163.html;. (man xopen_networking - http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html) ... There are two ways to obtain X/Open Sockets functionality: * Method A is in compliance with X/Open compilation specification. * Method B slightly deviates from X/Open compilation specification. However, Method B allows a program to include both objects compiled to X/Open Sockets specification and objects compiled to BSD Sockets specification. ... PostgreSQL support X/Open Sockets. Apache web server (2.2.15, /opt/hpws22/apache) and Perl (5.8.8, /opt/perl_64) are BSD Socket applications that are default with the OS. I tried Method B (It provides wrapper _xpg_ socket functions that allows using X/Open socket objects and BSD socket objects in the same binary) to build PostgreSQL 9.1 code, I LD_PRELOAD the generated libpq binary, without any other change both perl and apache work fine with postgresql now,and it is easy to implement too. We just need to build the source code with -D_XOPEN_SOURCE=600 -D_HPUX_ALT_XOPEN_SOCKET_API and link binary with libc. PFA patch. Thanks. AFAICT, the proposed patch will break things on at least some versions of HPUX. You can't just arbitrarily remove the reference to -lxnet, at least not without explaining to us why the existing comment about it is wrong. Likewise, removing -D_XOPEN_SOURCE_EXTENDED isn't acceptable without a whole more supporting evidence than you've provided. (I'm fairly certain that the latter will break the build on my old HPUX 10.20 box, for example.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
