Python-2.3.4 on OSF1 V4.0?

[Edmond Rusjan]

Hi All,

I'd like to use Python-2.3.4 on OSF1 V4.0, but have trouble
installing.
With a plain "./configure; make" build, I cannot import socket.
If I uncomment the socketmodule in Modules/Setup, the build fails.
Using gcc 3.4.2. Had no problem on OSF1 V5.1, Linux and Sun.
Have not been able to find reference to a similar problem in
comp.lang.python.

Thanks for any tip or reference,
Edmond

Details:

Plain "./configure; make" build:
[Python-2.3.4_no_socket]$ ./python
Python 2.3.4 (#4, Nov 17 2004, 17:01:35)
[GCC 3.4.2] on osf1V4
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
...
import _socket
ImportError: No module named _socket
With "_socket socketmodule.c" uncommented in Modules/Setup:
[Python-2.3.4]$ make
gcc -pthread -o python \
Modules/python.o \
libpython2.3.a -lrt -lm
_Esetsockopt
_Egetsockopt
_Erecv
_Esend
_Esendto
_Econnect
_Ebind
collect2: ld returned 1 exit status
make: *** [python] Error 1

Wrote, compiled and ran a simple test program which binds to a socket
and listens: no problem.

First few line of config.log:
....
It was created by python configure 2.3, which was
generated by GNU Autoconf 2.57. Invocation command line was

$ ./configure

## --------- ##
## Platform. ##
## --------- ##

hostname = alpha-s16.ajb.org
uname -m = alpha
uname -r = V4.0
uname -s = OSF1
uname -v = 1229

/usr/bin/uname -p = alpha
/bin/uname -X = unknown

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = alpha
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /usr/users/ajbddg/edmond/tools2/bin
PATH: /usr/users/ajbddg/edmond/tools/bin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/sbin
PATH: /sbin
PATH: /usr/local/bin
PATH: /u01/app/oracle/product/8.1.6/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1402: checking MACHDEP
configure:1511: result: osf1V4
configure:1517: checking EXTRAPLATDIR
configure:1532: result:
configure:1545: checking for --without-gcc
configure:1594: result: no
configure:1600: checking for --with-cxx=<compiler>
configure:1621: result: no
configure:1640: checking for c++
configure:1656: found /usr/users/ajbddg/edmond/tools2/bin/c++
configure:1666: result: c++
configure:1707: checking for C++ compiler default output
configure:1710: c++ conftest.cc >&5
configure:1713: $? = 0
configure:1759: result: a.out
configure:1764: checking whether the C++ compiler works
configure:1770: ./a.out
configure:1773: $? = 0
configure:1790: result: yes
configure:1797: checking whether we are cross compiling
configure:1799: result: no
configure:1802: checking for suffix of executables
configure:1804: c++ -o conftest conftest.cc >&5
configure:1807: $? = 0
configure:1832: result:
configure:1906: checking for gcc
configure:1922: found /usr/users/ajbddg/edmond/tools2/bin/gcc
configure:1932: result: gcc
configure:2176: checking for C compiler version
configure:2179: gcc --version </dev/null >&5
gcc (GCC) 3.4.2
....

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

With a plain "./configure; make" build, I cannot import socket.
If I uncomment the socketmodule in Modules/Setup, the build fails.
Using gcc 3.4.2. Had no problem on OSF1 V5.1, Linux and Sun.
Have not been able to find reference to a similar problem in
comp.lang.python. [...]
gcc -pthread -o python \
Modules/python.o \
libpython2.3.a -lrt -lm
_Esetsockopt
_Egetsockopt
_Erecv
_Esend
_Esendto
_Econnect
_Ebind

As a starting point, you need to find out what library you need to
link in to provide these symbols. Strategies to find that out are
1. setsockopt(2)
2. nm /usr/lib/*.a|grep setsockopt
3. try -lsocket

Regards,
Martin

 

[Edmond Rusjan]

Martin,

Thank you for the pointers, I appreciate. Still not out of the woods
though ...

As a starting point, you need to find out what library you need to
link in to provide these symbols. Strategies to find that out are
1. setsockopt(2)

man setsockopt does not mention any libraries - guess that means it's
in libc

2. nm /usr/lib/*.a|grep setsockopt

$ nm /usr/lib/*.a |grep setsockopt setsockopt |
setsockopt | 0000000000000000 | U |
0000000000000008
setsockopt | 0000000000000000 | U |
0000000000000008
setsockopt | 0000000000000000 | U |
0000000000000008
setsockopt | 0000000000000000 | U |
0000000000000008
__setsockopt | 0000000000000000 | U |
0000000000000008
__setsockopt | 0000000000000000 | U |
0000000000000008
/usr/lib/libc.a[setsockopt.o]:
__setsockopt | 0000000000000016 | T |
0000000000000008
setsockopt | 0000000000000016 | T |
0000000000000008
__setsockopt | 0000000000000000 | U |
0000000000000008
__setsockopt | 0000000000000000 | U |
0000000000000008
/usr/lib/libc_r.a[setsockopt.o]:
__setsockopt | 0000000000000016 | T |
0000000000000008
setsockopt | 0000000000000016 | T |
0000000000000008
setsockopt | 0000000000000000 | U |
0000000000000008
setsockopt | 0000000000000000 | U |
0000000000000008

man nm says T means external text, so if I am reading correctly this
confirms setsockopt is in libc

3. try -lsocket

$ find /usr -name libsocket.a
$ find /usr -name libsocket.so

Also,
$ c++ -pthread -o python Modules/python.o libpython2.3.a -lsocket -lrt
-lm
/usr/bin/ld:
Can't locate file for: -lsocket
collect2: ld returned 1 exit status

On Sun, yes, it uses -lsocket and configure script figures that out.


Here's my little test program:

/*
* to help build python
* gcc -o s s.c
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
int ss, s, clilen, n, i;
struct sockaddr_in cli_addr, serv_addr;
char buf[512];

if ( (ss = socket(AF_INET, SOCK_STREAM, 0)) < 0 )
{
perror("can't open socket");
exit(-1);
}

memset( &serv_addr, 0, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(12345);

if ( bind( ss, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) <
0 )
{
perror("can't bind to port\n");
exit(-1);
}

listen(ss, 2);

clilen = sizeof(cli_addr);
s = accept( ss, (struct sockaddr *) &cli_addr, &clilen);

if (s < 0)
{
perror("server accept error");
}

for ( i=1; ; i++)
{
memset( buf, 0, 512);
if ( (n=read(s, buf, 512)) == 0) break;
printf("%d th message: %s; length: %d \n", i, buf, n);
}

close(s);

(void) printf("Hello socket!\n");

exit(0);
}

Compiles and runs ... never have to specify any library to make socket
work:
$ gcc -o s s.c]$ ./s &
[1] 12491
$ netstat -a |grep 12345
tcp 0 0 *.12345 *.*
LISTEN
$ telnet 12345
Trying 0.0.48.57...


Perhaps comparing the succesful OSF1 V5.1 and failed OSF1 V4.0 buils
may help:

[V5.1]$ ./configure |grep socket
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking for socket in -lsocket... no

[V5.1]$ make |grep socket
building '_socket' extension
gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fno-strict-aliasing -I.
-I/dat0/ajb/app/edmond/src/buildSandbox/Python-2.3.4/./Include
-I/usr/local/include
-I/dat0/ajb/app/edmond/src/buildSandbox/Python-2.3.4/Include
-I/dat0/ajb/app/edmond/src/buildSandbox/Python-2.3.4 -c
/dat0/ajb/app/edmond/src/buildSandbox/Python-2.3.4/Modules/socketmodule.c
-o build/temp.osf1-V5.1-alpha-2.3/socketmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V5.1-alpha-2.3/socketmodule.o -L/usr/local/lib -o
build/lib.osf1-V5.1-alpha-2.3/_socket.so

[V5.1]$ find . -name _socket.so
../build/lib.osf1-V5.1-alpha-2.3/_socket.so

[V5.1]$ nm build/lib.osf1-V5.1-alpha-2.3/_socket.so |grep setsockopt
setsockopt | 0000000000000000 | U |
0000000000000000
setsockopt_doc | 0004398043894268 | d |
0000000000000000
setsockopt_doc:S1006=ar56;000000000000000000000000;000000000000000000000232;2
| 0004398043894268 | d | 0000000000000001
sock_setsockopt | 0004396970424912 | t |
0000000000000008
sock_setsockopt:f267 | 0004396970424912 | t |
0000000000000008


[V4.0]$ ./configure |grep socket
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking for socket in -lsocket... no


[V4.0]$ make |grep socket
building '_socket' extension
gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fno-strict-aliasing -I.
-I/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/./Include
-I/usr/local/include
-I/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Include
-I/u101/ajbddg/edmond/src/sandbox/Python-2.3.4 -c
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c -o
build/temp.osf1-V4.0-alpha-2.3/socketmodule.o
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:
In function `sock_accept':
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:1137:
warning: passing arg 3 of `accept' from incompatible pointer type
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:
In function `sock_getsockopt':
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:1361:
warning: passing arg 5 of `getsockopt' from incompatible pointer type
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:1379:
warning: passing arg 5 of `getsockopt' from incompatible pointer type
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:
In function `sock_getsockname':
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:1623:
warning: passing arg 3 of `getsockname' from incompatible pointer type
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:
In function `sock_getpeername':
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:1651:
warning: passing arg 3 of `getpeername' from incompatible pointer type
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:
In function `sock_recvfrom':
/u101/ajbddg/edmond/src/sandbox/Python-2.3.4/Modules/socketmodule.c:1898:
warning: passing arg 6 of `recvfrom' from incompatible pointer type
ld -shared -expect_unresolved *
build/temp.osf1-V4.0-alpha-2.3/socketmodule.o -L/usr/local/lib -o
build/lib.osf1-V4.0-alpha-2.3/_socket.so
*** WARNING: renaming "_socket" since importing it failed: Unresolved
symbol in build/lib.osf1-V4.0-alpha-2.3/_socket.so: _Esetsockopt

[V4.0]$ find . -name '_socket*'
../PCbuild/_socket.dsp
../build/lib.osf1-V4.0-alpha-2.3/_socket_failed.so

[V4.0]$ nm build/lib.osf1-V4.0-alpha-2.3/_socket_failed.so |grep
setsockopt
_Esetsockopt | 0000000000000000 | U |
0000000000000000
setsockopt_doc | 0004398043893924 | d |
0000000000000000
setsockopt_doc:S794=ar55;000000000000000000000000;000000000000000000000232;2
| 0004398043893924 | d | 0000000000000008
sock_setsockopt | 0004396970422608 | t |
0000000000000008
sock_setsockopt:f238 | 0004396970422608 | t |
0000000000000008

I don't understand if the '_E' in '_Esetsockopt' is significant and/or
where it comes from, but that's one difference that strikes me.

[V4.0]$ grep setsockopt Modules/socketmodule.c|wc
11 39 498
[V4.0]$ grep _Esetsockopt Modules/socketmodule.c|wc
0 0 0

Thank you in advance for your help.
Edmond

 

[Fredrik Lundh]

I don't understand if the '_E' in '_Esetsockopt' is significant and/or
where it comes from, but that's one difference that strikes me.

[V4.0]$ grep setsockopt Modules/socketmodule.c|wc
11 39 498
[V4.0]$ grep _Esetsockopt Modules/socketmodule.c|wc
0 0 0

the OSF/1 C libraries support multiple Unix dialects through a variety of
compatibility macros. I'm not 100% sure, but I think _E is used for things
that explicitly require some level of X/Open-compatibility.

try adding a

#define _XOPEN_SOURCE_EXTENDED

to your test program (before you include the socket stuff), and see if
it still works.

if that breaks your test program, adding a corresponding #undef to the
socket module's source code might help.

</F>

 

[Edmond Rusjan]

Thank you so much, Martin and Fredrik.

As you advised, added near the top of socketmodule.c (after #import Python.h):

#undef _XOPEN_SOURCE_EXTENDED
#define _POSIX_PII_SOCKET
#undef HAVE_SOCKADDR_SA_LEN

It built cleanly and socket now imports.