The connect function faild when linking with libxnet.sl

[zfm_1]

I’m porting an application from SUN to HP itanium, this application suppose to call the socket connect function so it was linked to libxnet.so on SUN, however when I port this application to HP it linked to libxnet.sl and when it comes to call “connect” it gives the following errors and terminated
Thu, 23 Oct 2008 19:12:58.0000000 [itanium:11030] (IT_ATLI2_IP:101) W -
ATLI2 failure creating connection with minor_code 1230242762 occurred in
IPPoolImpl::create_connection()

Thu, 23 Oct 2008 19:12:58.0000000 [itanium:11030] (IT_ATLI2_IP:102) W -
ATLI2 failure caused by function ::connect() failing with system error 4 ('Interrupted system call')

However when I remove the libxnet.sl form the link line the connect function working ok…?

Any explanation
Thanks in advance

[Dennis Handly · Accepted solution]

>However when I remove the libxnet.sl form the link line the connect function working ok?
>Any explanation

I think you have answered your question, don't use libxnet.sl. Where does this library exist? If it comes from HP-UX it would be libxnet.so. If it's in /usr/local/lib, don't use it.

[Steven Schweda]

Perhaps you should stop trying to use every
library you used on Solaris. It might be
wiser to start with none, and then add what
you need.

[zfm_1]

Thanks for Dennis and Steven for the reply, although i know that removing this lib from the link is fixing the problem, I am looking for any explanation why linking to that lib cause a problem

thanks in advance

[Dennis Handly]

>I am looking for any explanation why linking to that lib cause a problem

You didn't mention the path to that shlib? If it doesn't come from HP, that could be the cause.
Looking at connect(2), there are many conflicting definitions of it, perhaps that bad shlib implements the wrong standard.

[zfm_1]

the lib path is /usr/lib/libxnet.sl

[Dennis Handly]

>the lib path is /usr/lib/libxnet.sl

This directory isn't valid for Integrity. This is for PA applications only.
This old document mentions libxnet:
http://docs.hp.com/en/5964-5283/ch06s15.html

[Dennis Handly]

connect(2) is defined in these shlibs:
/usr/lib/hpux32/libc.so
/usr/lib/hpux32/libxnet.so

[zfm_1]

i try to use /usr/lib/hpux64/libxnet.so however the application still crash

[Dennis Handly]

>i try to use /usr/lib/hpux64/libxnet.so however the application still crash

We told you not to use that shlib! And to read the connect(2) carefully.
I was just listing it so everyone would know the exact path and spelling.

[zfm_1]

thanks dennis very much for your help and support

[Dennis Handly]

>i try to use /usr/lib/hpux64/libxnet.so

One issue with a 64 bit application, socklen_t and size_t may have different sizes. So unless you are looking and correcting warnings, they may be picking up bogus lengths.

[Michael Lutz CA]

The xnet library supports the XOPEN socket calls while the c library supports the HPUX sockets. HP has advised developers to move from the HPUX sockets to XOPEN. I am having trouble with the XOPEN sockets hanging but working properly with the HPUX sockets. It makes me wonder if all my sources have the correct -D defines in place. Does anyone know if there is a way to test the executable (or object files) to see which socket protocol is being referenced?

[Dennis Handly]

>Michael: if all my sources have the correct -D defines in place. Does anyone know if there is a way to test the executable (or object files) to see which socket protocol is being referenced?

First of all, do you know the differences with the -D? If this just changes the instructions, that would be hard to check. If it changes the functions, you could scan with nm(1). Of course you could have the wrong shlib, so just looking at chatr(1) may not help.

[amit dwivedi]

Important points:
1.In prior releases, if an executable includes binary objects compiled to X/Open Sockets and binary objects compiled to BSD specification, it may result in unexpected
behavior, including abnormal termination and unexpected socket errors. This
problem can now be avoided by:

â Define _HPUX_ALT_XOPEN_SOCKET_API, in addition to either defining
_XOPEN_SOURCE=600 in UNIX03, or _XOPEN_SOURCE and
_XOPEN_SOURCE_EXTENDED in UNIX95;
â Link with C library instead of Xnet library. Xnet library should not be included
in the link line.

2.The following interfaces and system calls are impacted by UNIX 2003 Conformance:
â To conform to UNIX 2003, customers must define _XOPEN_SOURCE to 600. To
conform to UNIX 95, customers must continue to define _XOPEN_SOURCE and
_XOPEN_SOURCE_EXTENDED. Please note that applications using the X/Open
Sockets must be linked with the Xnet library for UNIX 2003 and UNIX 95 conformance.

The points are from HP-UX 11i Version 3 Release Notes

3.from man page(xopen_networking(7))
Note if the C library is also specified in the link line, the Xnetlibrary has to be specified before the C library. Otherwise, X/Open Sockets calls would have been resolved to BSD Sockets functions in the C library instead of X/Open Sockets functions in the Xnet library.

the above statement is a contradictory as both libc and xnet library are in the same directory.

I guess that was the main problem.
FINAL WORDS:
I guess HP has correct this problem in release B.11.31(current release level of the operating, uname -r)

[amit dwivedi]

>>the above statement is a contradictory as both libc and xnet library are in the same directory.

please accept my apologies for the above wrong statement.