Bugs item #728330, was opened at 2003-04-27 11:21
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470
Category: Installation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 9
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Trent Mick (tmick)
Summary: Don't define _SGAPI on IRIX
Initial Comment:
Python release:
2.3b1
Platform:
IRIX 6.5
MIPSpro Compilers: Version 7.3.1.2m
Commands used:
./configure --prefix=/usr/local_cci/Python-2.3b1t
make
The socket module fails to compile. The output from
the compiler is attached.
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-30 14:55
Message:
Logged In: YES
user_id=21627
I have applied this patch as socketmodule.c 1.271.6.9.
As for timeliness: it is confusing to have "half-closed"
reports. After the patch had been applied to the mainline,
and not simultaneously to an older branch, this patch should
have been closed, and a new patch submitted, where the
subject indicates that this is a backport of a patch that
has already been applied.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-30 14:43
Message:
Logged In: YES
user_id=71407
> It's probably also worth noting that socketmodule seems to
> require different things for every single release of Irix.
> I'd hope that any new patch wouldn't break other versions
> of Irix.
The patch in question is not new. The same patch is in 2.4
final and does not appear to cause any problems.
I maintain two IRIX machines with versions 6.5.10 and 6.5.21.
These machines are not meant to be upgraded. I have access
to another IRIX machine which is upgraded regularly. This
machine is currently running version 6.5.25. Python 2.4 works
fine on all three machines.
> (sgi+socketmodule is becoming the new hp/ux+threads)
I will keep an eye on IRIX/Python compatibility. If we could
just work out a way of applying patches in a timely fashion
there would be almost no problem.
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-12-30 12:49
Message:
Logged In: YES
user_id=29957
It's probably also worth noting that socketmodule seems to
require different things for every single release of Irix.
I'd hope that any new patch wouldn't break other versions of
Irix.
(sgi+socketmodule is becoming the new hp/ux+threads)
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-30 11:53
Message:
Logged In: YES
user_id=71407
> The 2.3 patch is wrong (assuming you are talking about
> py234c1_socketmodule_patch).
I am talking about the patch in my message from 2004-09-14
21:20.
> Please attach patches rather than pasting them in the
> comment box, and please use unified or context rather than
> plain diffs.
All right.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2004-12-30 11:22
Message:
Logged In: YES
user_id=21627
The 2.3 patch is wrong (assuming you are talking about
py234c1_socketmodule_patch). It conditionalizes inclusion
of addrinfo.h on __sgi being defined; thus breaking all
systems that require inclusion of addrinfo.h.
Please attach patches rather than pasting them in the
comment box, and please use unified or context rather than
plain diffs.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-24 20:35
Message:
Logged In: YES
user_id=71407
> Can this be closed?
As far as I know my patch for the release23-maint line is still
not checked in. This patch is (almost) the same as the one
that is now in 2.4 final and does not appear to cause any
problems. Could someone please apply my patch to the
release23-maint branch?
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-24 16:50
Message:
Logged In: YES
user_id=80475
Can this be closed?
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-10-26 09:27
Message:
Logged In: YES
user_id=71407
How is my 2004-09-09 patch for the main line doing in 2.4b1?
Does my 2004-09-14 submission for the release23-maint
branch need any tweaking? AFAICT from the viewcvs page at
SourceForge it is still not checked in.
Thanks!
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-09-15 06:20
Message:
Logged In: YES
user_id=71407
Hi Trent,
> Sorry for the delay. Your final socketmodule changes are
> finally checked in.
Thanks!!!
> Yes, that is the correct tag for the latest Py2.3 code.
> So you are going to look into the relevant bits to backport
> for Py2.3 compilation on IRIX then?
Here is the patch (based on socketmodule.c CVS rev.
1.271.6.8):
Index: socketmodule.c
==============================================
=====================
RCS
file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,
v
retrieving revision 1.271.6.8
diff -r1.271.6.8 socketmodule.c
194a195
> #undef _SGIAPI /* to avoid warning */
196a198,206
> #undef _XOPEN_SOURCE
> #include <sys/socket.h>
> #include <sys/types.h>
> #include <netinet/in.h>
> #ifdef _SS_ALIGNSIZE
> #define HAVE_GETADDRINFO 1
> #define HAVE_GETNAMEINFO 1
> #endif
>
262c272,284
< #include "addrinfo.h"
---
> /* include Python's addrinfo.h unless it causes trouble */
> #if defined(__sgi) && _COMPILER_VERSION>700 && defined
(_SS_ALIGNSIZE)
> /* Do not include addinfo.h on some newer IRIX versions.
> * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21,
> * for example, but not by 6.5.10.
> */
> #elif defined(_MSC_VER) && _MSC_VER>1200
> /* Do not include addrinfo.h for MSVC7 or greater.
> * addrinfo and EAI_* constants are defined in ws2tcpip.h
> */
> #else
> # include "addrinfo.h"
> #endif
Tested on these platforms:
6.5.10 with MIPSpro 7.3.1.2
6.5.21 with MIPSpro 7.41
6.5.25 with MIPRpro 7.3.1.3
RedHat 8.0, gcc 3.2
Tru64 UNIX V5.1, C V6.3-028
For your convenience and reference:
wget
http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6
_8_patched_c
Cheers,
Ralf
----------------------------------------------------------------------
Comment By: Trent Mick (tmick)
Date: 2004-09-13 19:50
Message:
Logged In: YES
user_id=34892
Ralf,
Sorry for the delay. Your final socketmodule changes are
finally checked in.
Checking in socketmodule.c;
/cvsroot/python/python/dist/src/Modules/socketmodule.c,v
<-- socketmodule.c
new revision: 1.306; previous revision: 1.305
>> Can you take over any relevant 2.3 work?
>
> Which CVS tag should I be using? release23-maint?
Yes, that is the correct tag for the latest Py2.3 code.
So you are going to look into the relevant bits to backport
for Py2.3 compilation on IRIX then?
Cheers,
Trent
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-09-09 12:52
Message:
Logged In: YES
user_id=71407
Sorry for the delay. It took 6+ hours for revision 1.305 to
show up in the anonymous cvs.
> Do those other patch bits need to go in for IRIX compilation?
Absolutely.
I've made a new patch again, based on socketmodule.c
revision 1.305:
Index: socketmodule.c
==============================================
=====================
RCS
file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,
v
retrieving revision 1.305
diff -u -r1.305 socketmodule.c
--- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305
+++ socketmodule.c 9 Sep 2004 10:25:29 -0000
@@ -192,8 +192,18 @@
/* XXX Using _SGIAPI is the wrong thing,
but I don't know what the right thing is. */
+#undef _SGIAPI /* to avoid warning */
#define _SGIAPI 1
+#undef _XOPEN_SOURCE
+#include <sys/socket.h>
+#include <sys/types.h>
+#include <netinet/in.h>
+#ifdef _SS_ALIGNSIZE
+#define HAVE_GETADDRINFO 1
+#define HAVE_GETNAMEINFO 1
+#endif
+
#define HAVE_INET_PTON
#include <netdb.h>
#endif
Tested again on these platforms:
6.5.10 with MIPSpro 7.3.1.2
6.5.21 with MIPSpro 7.41
6.5.25 with MIPRpro 7.3.1.3
RedHat 8.0, gcc 3.2
For your convenience and reference:
wget
http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p
atched_c
It may be most convenient to wget the complete file as
shown, mv, cvs diff.
> Can you take over any relevant 2.3 work?
Which CVS tag should I be using? release23-maint?
----------------------------------------------------------------------
Comment By: Trent Mick (tmick)
Date: 2004-09-07 19:51
Message:
Logged In: YES
user_id=34892
Now checked in to Python CVS (socketmodule.c revision 1.305)
Ralf,
Note that I just submitted the #ifdef'ery stuff that I
posted and (I now see) not all the stuff that you have in
http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch
Do those other patch bits need to go in for IRIX
compilation? Can you take over any relevant 2.3 work?
----------------------------------------------------------------------
Comment By: Trent Mick (tmick)
Date: 2004-09-07 18:07
Message:
Logged In: YES
user_id=34892
> The new patch didn't make it into Python 2.4, alpha 3.
> Is it still not good?
No, I just dropped the ball. I'll look into it right now.
----------------------------------------------------------------------
Comment By: Steven Queen (squeen)
Date: 2004-09-07 12:49
Message:
Logged In: YES
user_id=883896
> #define _BSD_TYPES
> You could try adding this to the top of bsddbmodule.c in
> Python 2.3.4.
I did as you suggested and added the define (before #include
"Python.h") at the top of bsdmodule.c and _ssl.c. Both not
compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank
you again!
The last remaining warning reads:
building 'bsddb185' extension
cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o
build/temp.irix64-6.5-2.3/bsddbmodule.o
ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o
[...] -o build/lib.irix64-6.5-2.3/bsddb185.so
*** WARNING: renaming "bsddb185" since importing it failed:
14768:./python: rld: Fatal Error: unresolvable symbol in
build/lib.irix64-6.5-2.3/bsddb185.so: dbopen
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-09-06 21:03
Message:
Logged In: YES
user_id=71407
> But it is not compileable in Python 2.3.4.
That's expected because I took out this part of my original
2.3.4c1 patch:
#if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI
#define _BSD_TYPES
#endif
2.4 doesn't require this anymore because _BSD_TYPES is
already defined in pyconfig.h. For 2.3.4 you have to put it
back near the top of socketmodule.c.
I'll post a patch against the 2.3 maintenance branch after the
2.4 patch is in the CVS. Holding my breath...
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2004-09-05 19:39
Message:
Logged In: NO
The patch worked for python 2.4 a2. But I patched the
configured source tree (no gmake distclean, ./configure).
But it is not compileable in Python 2.3.4. Syntax error
about "struct python.api" and some other. I will post this
tomorrow (06.09.04).
Environment:
SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24.
--maik./
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-09-04 07:39
Message:
Logged In: YES
user_id=71407
The new patch didn't make it into Python 2.4, alpha 3.
:( :( :(
Is it still not good?
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-08-26 19:03
Message:
Logged In: YES
user_id=71407
> I still see compile errors in bsddbmodule.c and _ssl.c
> during to missing types for u_short, u_int, u_long, etc.
Yesterday I noticed that bsddbmodule.c compiles correctly
with the latest Python CVS. Maybe this is because the latest
pyconfig.h defines this:
#define _BSD_TYPES
You could try adding this to the top of bsddbmodule.c in
Python 2.3.4.
----------------------------------------------------------------------
Comment By: Steven Queen (squeen)
Date: 2004-08-26 18:50
Message:
Logged In: YES
user_id=883896
Oops, previous message should have read:
... applied your patch and socketmodule is NOW working in
Python 2.3.4 for me.
Sorry.
----------------------------------------------------------------------
Comment By: Steven Queen (squeen)
Date: 2004-08-26 18:49
Message:
Logged In: YES
user_id=883896
I just ran into this same problem using the MIPSpro 7.4.2
compiler under IRIX 6.5.23. I applied your patch and
socketmodule is not working in Python 2.3.4 for me. THANK YOU.
I still see compile errors in bsddbmodule.c and _ssl.c
during to missing types for u_short, u_int, u_long, etc.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-08-25 22:34
Message:
Logged In: YES
user_id=71407
I forgot to mention that the patch and the patched file are
also available here, along with the original code:
http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c
http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p
atch
http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p
atched_c
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-08-25 22:30
Message:
Logged In: YES
user_id=71407
I will attach a complete patch for SGI, based on Trent's work.
I've tested on these platforms:
6.5.10 with MIPSpro 7.3.1.2
6.5.21 with MIPSpro 7.41
6.5.25 with MIPRpro 7.3.1.3
RedHat 8.0, gcc 3.2
Comments:
- Trent's fragment has a small error: __SS_ALIGNSIZE, should
be _SS_ALIGNSIZE. Other than that it was fine.
- I guess the Python 2.3 maintenance branch should also be
patched to correct my flaw.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2004-08-25 21:45
Message:
Logged In: YES
user_id=21627
tmick, from inspection only, your last patch seems clear and
correct - especially as it has comments in it :-)
I would leave the OS/2 part out - I somewhat doubt that any
compiler on that platform provides EAI_*, and even if it
would: addrinfo.h typically ends up empty if the system has
"proper" getaddrinfo support, so including it should not
hurt even on systems where it isn't used.
----------------------------------------------------------------------
Comment By: Trent Mick (tmick)
Date: 2004-08-25 19:30
Message:
Logged In: YES
user_id=34892
Would ifdef'ery like the following be a little bit more
clear and still work?
/* include Python's addrinfo.h unless it causes trouble */
#if defined(__sgi) && _COMPILER_VERSION>700 &&
defined(__SS_ALIGNSIZE)
/* Do not include addinfo.h on some newer IRIX versions.
* __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21,
* for example, but not by 6.5.10.
*/
#elif defined(_MSC_VER) && _MSC_VER>1200
/* Do not include addrinfo.h for MSVC7 or greater.
* addrinfo and EAI_* constants are defined in ws2tcpip.h
*/
#else
# include "addrinfo.h"
#endif
...an additional #elif block might be necessary for OS/2 EMX
(but let's figure that out later).
Ralf,
Would you be able to try a Python build with the latest
Python CVS and replace the bare #include "addrinfo.h" on
line 260 of socketmodule.c with the above block. Does that
work for you? If so then I think this should be a basis for
a corrected patch for socketmodule.c.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-08-25 18:59
Message:
Logged In: YES
user_id=71407
Mick is right. Unfortunately my patch from May had a flaw. It
should have been something along the lines of
#if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined
(_SS_ALIGNSIZE))
# include "addrinfo.h"
#endif
Sorry for the oversight.
----------------------------------------------------------------------
Comment By: Trent Mick (tmick)
Date: 2004-08-25 18:26
Message:
Logged In: YES
user_id=34892
I am using this block in my builds. I *think* that this
preserves the intentions of the IRIX and MSVC6 patches and
am less sure about the OS/2 EMX-related part (see the
python-dev thread for a reference).
#if defined(__sgi)
# if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in
sys/socket.h
*/
/* by some newer versions of
IRIX */
/* (e.g. not by 6.5.10 but by
6.5.21) */
# include "addrinfo.h"
# endif
#elif defined(PYOS_OS2)
# if defined(PYCC_GCC)
# include "addrinfo.h"
# endif
#elif defined(_MSC_VER)
# if _MSC_VER == 1200
# include "addrinfo.h"
# endif
#else
# include "addrinfo.h"
#endif
----------------------------------------------------------------------
Comment By: Trent Mick (tmick)
Date: 2004-08-25 18:09
Message:
Logged In: YES
user_id=34892
Related thread on python-dev:
http://mail.python.org/pipermail/python-dev/2004-August/048341.html
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2004-08-25 08:26
Message:
Logged In: YES
user_id=21627
Indeed, this broke a number of platforms, so I backed it out.
----------------------------------------------------------------------
Comment By: John Ehresman (jpe)
Date: 2004-07-10 20:41
Message:
Logged In: YES
user_id=22785
This seems to break the building of CVS HEAD sources on
windows with VC++ 6 because addrinfo.h is not included and
HAVE_GETADDRINFO is not defined in my build. It also may
break on other platforms where HAVE_GETADDRINFO is not
defined. Maybe addrinfo.h should be included if not on sgi.
I know that VC++ 6 isn't the primary compiler for Python
2.4, but it works otherwise and it presumably will be the
primary compiler for 2.3.5.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-05-27 12:28
Message:
Logged In: YES
user_id=6656
Closing!
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-05-27 09:17
Message:
Logged In: YES
user_id=29957
There's a note on the 2.3.4 bugs page pointing at this bug.
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-05-27 07:41
Message:
Logged In: YES
user_id=29957
If the patch is good, I'll make sure it's included in the
2.3.4 'bugs' page.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-05-27 06:14
Message:
Logged In: YES
user_id=71407
> Can you try gmake?
Yes, it works with gmake. I've verified that the socket
module on the CVS head builds and runs correctly on the
three platforms mentioned in my message from 2004-05-
22 01:23. There are not even warnings.
> Is IRIX make particularly braindead?
I don't think so. It works with most auto-configured
packages incl. all earlier versions of Python. But I'll save
this for another day when the first 2.4 beta release is
out.
Thank you for your help! I think this tracker issue should
be closed.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-05-26 20:19
Message:
Logged In: YES
user_id=6656
Uh, that's odd. Is IRIX make particularly braindead?
Can you try gmake? Maybe we've let something non-portable slip
in. At any rate, I think this should be done in a separate report...
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-05-26 20:14
Message:
Logged In: YES
user_id=71407
I checked out the python cvs head from scratch and ran
configure in the usual way, with the usual result.
However, make doesn't work:
% make
don't know how to make Parser/printgrammar.o (bu42).
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-05-26 19:07
Message:
Logged In: YES
user_id=6656
OK, so I've commited revision 1.289 of Modules/socketmodule.c.
Can you check if CVS HEAD works for you now?
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-05-26 18:59
Message:
Logged In: YES
user_id=71407
> Is there any chance of the Right Thing actually
happening?
The experience of the last 13 months suggests "No."
SGI's freeware team has not responded to my report for
more than a year. I am absolutely not a SGI or socket
expert. I only worked on the patch because I was
desperate enough and because Maik had already done
the groundwork.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-05-26 18:27
Message:
Logged In: YES
user_id=6656
Is this really The Right Thing? I still see
/* XXX Using _SGIAPI is the wrong thing,
but I don't know what the right thing is. */
Is there any chance of the Right Thing actually happening? If not,
I'll check this into HEAD, and if that seems to work, move it to
release23-maint in time for 2.3.5.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-05-22 10:23
Message:
Logged In: YES
user_id=71407
Based on Maik's posting from 2004-03-08 08:53 I've
worked out a small
bug-fix patch relative to Python-2.3.4c1 that leads to
successful
creation of _socket.so under three different versions of
IRIX:
6.5.10 with MIPSpro 7.3.1.2
6.5.21 with MIPSpro 7.41
6.5.23 with MIPRpro 7.3.1.3
I've consistently used
#if defined(__sgi) && _COMPILER_VERSION>700
to restrict the changes to IRIX. However, to be sure I've
also verified
that the Python installation is still OK under Redhat 8
and Tru64 Unix
5.1.
I will upload the patch. It is also available here:
http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod
ule_patch
For completeness I've also posted these files:
http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod
ule_patched_c
http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod
ule_original_c
I've made an effort to keep the patch minimally
intrusive, but it is
certainly not "clean." However, the status quo is so bad
that it can
only get better. We have not been able to switch to
Python 2.3 because
of the problems with the socket module. It would be
fantastic if
the bug-fix patch could be included in the 2.3.4 final
distribution.
----------------------------------------------------------------------
Comment By: Maik Hertha (mhertha)
Date: 2004-03-08 17:53
Message:
Logged In: YES
user_id=768223
I got Python 2.3.3 compiled with MipsPro Compilers: Version
7.3.1.3m. The following changes were made to satisfy all needs.
Line 206 in Modules/socketmodule.c
#define _SGIAPI 1
NEW: #undef _XOPEN_SOURCE
NEW: #define HAVE_GETADDRINFO 1
NEW: #define HAVE_GETNAMEINFO 1
#define HAVE_INET_PTON
NEW: #include <sys/types.h>
NEW: #include <sys/socket.h>
NEW: #include <netinet/in.h>
#include <netdb.h>
Line 269:
/* #include "addrinfo.h" */
In addition to this I extend the CFLAGS with -D_BSD_TYPES to
satisfy the u_short and friends definition.
--maik./
----------------------------------------------------------------------
Comment By: Bill Baxter (billbaxter26)
Date: 2004-03-03 17:20
Message:
Logged In: YES
user_id=892601
Got it down to one error:
% > ./python Lib/test/test_socket.py
Traceback (most recent call last):
File "Lib/test/test_socket.py", line 6, in ?
import socket
File "/usr/local/spider/lib/python2.3/socket.py", line 44,
in ?
import _socket
ImportError: 210454:./python: rld: Fatal Error: unresolvable
symbol in
/usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so:
_xpg5_accept
xpg5_accept does appear in any library on our SGI's that are
only 1-2 years old. It does appear in libc in very recent
revisions of Irix (> 6.5.19?)
Does anyone know how to get Python 2.3 to avoid the use of
xpg5_accept?
Thanks
----------------------------------------------------------------------
Comment By: Bill Baxter (billbaxter26)
Date: 2004-01-12 19:59
Message:
Logged In: YES
user_id=892601
Has anyone encountered problems with different versions of
IRIX 6.5? I finally got sockets to work in Python2.3.3, but
only on the most up-to-date version of IRIX (uname -v =
01100304). On any other machine with a lower version
(archetecture doesn't seem to matter), I get messages which
all seem to be related to sockets:
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_vsnprintf
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_recv
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_connect
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_bind
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_getsockopt
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_sendto
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_setsockopt
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_accept
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_recvfrom
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_socket
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_getsockname
Upgrading all of our SGIs is not something I have control
over.
----------------------------------------------------------------------
Comment By: Maik Hertha (mhertha)
Date: 2003-12-22 19:52
Message:
Logged In: YES
user_id=768223
Sorry if there is something unclear.
Redefine means: Set a value which is required to satisfy
ifdef-statements in the header files. As you see in the
definitions, given in the comment, the value for _NO_XOPEN4
is set as a result of some dependencies automatically
defined. A redefinition of _SGIAPI in the socketmodule.c is
not sufficient alone. Therefore to satisfy all requirements
in the header files, you should set the values for
_NO_XOPEN4 and _NO_XOPEN5 also manually.
Howto do in socketmodule.c?
...
#define _SGIAPI 1
#define _NO_XOPEN4 1
#define _NO_XOPEN5 1
...
If you are familiar with regular expressions, then you will
know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4,
_NO_XOPEN5.
Sorry if there was something wrong in my comment.
----------------------------------------------------------------------
Comment By: Bill Baxter (billbaxter26)
Date: 2003-12-22 16:49
Message:
Logged In: YES
user_id=892601
Can someone please clarify mherta's comment from 2003-12-16?
How should we "redefine _NO_XOPEN[45] in the socketmodule.c
at the same position like the _SGIAPI redefinition"?
Should those lines of code be added to socketmodule.c, or
are they the source of the problem?
Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5]
or are they all different?
Thanks.
----------------------------------------------------------------------
Comment By: Maik Hertha (mhertha)
Date: 2003-12-16 18:27
Message:
Logged In: YES
user_id=768223
I've tested the latest Python 2.3.3c1 to compile. The
problem reported is still present. To avoid the error
messages, about the incompatible types of several
netdb-functions (like inet_pton), you should redefine
_NO_XOPEN[45] in the socketmodule.c at the same position
like the _SGIAPI redefinition. If there are error messages
that types like u_short and u_char are not defined, please
add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay).
If anybody don't need a executable compiled with MipsPro,
gcc from the freeware.sgi.com could be a choice.
The problem for this seems in /usr/include/standards.h:
#define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) ||
(defined(_XOPEN_SOURCE) &&
(_XOPEN_SOURCE+0 >= 500)))
#define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) ||
(defined(_XOPEN_SOURCE) &&
(_XOPEN_SOURCE+0 < 500)))
As the first option is true (_XOPEN_SOURCE is set to 600 in
pyconfig.h) the second option will be false. The constant
#define NI_NUMERICHOST 0x00000002 /* return numeric form
of hostname */
is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5
(/usr/include/netdb.h) which is always false.
In the manual pages there is a example which uses the
constant NI_NUMERICHOST and compiles without error message.
I'm not sure to cut off the file pyconfig.h from compiling
the socketmodule.c?
Any comments?
----------------------------------------------------------------------
Comment By: Hans Nowak (zephyrfalcon)
Date: 2003-10-31 04:04
Message:
Logged In: YES
user_id=173607
My $0.02...
Yesterday I successfully compiled Python 2.3.2, with socket
module. I'm using an O2 running IRIX 6.5.11f.
I didn't encounter any of the problems described before, and
had no problems with _SGIAPI or anything. The reason it
didn't compile was that u_long and u_char were not defined
in some places; /usr/include/netinet/tcp.h to be precise,
and a Python file (getaddrinfo.c).
I'm using gcc 3.3 (the one downloaded from freeware.sgi.com).
If anyone is interested, drop me a mail at hans at
zephyrfalcon.org and I'll put the binary online somewhere.
----------------------------------------------------------------------
Comment By: Bill Baxter (billbaxter26)
Date: 2003-10-24 21:59
Message:
Logged In: YES
user_id=892601
Here's the output from 'gmake', using MIPSpro Compiler 7.30
on IRIX 6.5
Sorry, I don't know how to attach something using the "Add a
Comment" box. Is there another way to post?
The patch at
www.python.org/2.3.2/patches/sgi-socketmodule.patch was
edited into socketmodule.c :
#include <netdb.h>
#endif
/* GCC 3.2 on Irix 6.5 fails to define this variable at all.
Based on
the above code, I'd say that the SGI headers are just
horked. */
#if defined(__sgi) && !defined(INET_ADDRSTRLEN)
#define INET_ADDRSTRLEN 16
#endif
/* Generic includes */
#include <sys/types.h>
#include <signal.h>
---------------------------------------------------------------------------
cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include
-DPy_BUILD_CORE -c ./Modules/socketmodule.c -o
Modules/socketmodule.o
cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line =
195
Macro "_SGIAPI" (declared at line 210 of
"/usr/include/standards.h") has an
incompatible redefinition.
#define _SGIAPI 1
^
cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198
The identifier "socklen_t" is undefined.
extern int iruserok_sa(const void *, socklen_t, int, const
char *,
^
cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145
Macro "_SS_ALIGNSIZE" (declared at line 246 of
"/usr/include/sys/socket.h")
has an incompatible redefinition.
#define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG))
^
cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line =
822
The identifier "NI_NUMERICHOST" is undefined.
NI_NUMERICHOST);
^
cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line =
3054
A value of type "int" cannot be assigned to an entity of
type "const char *".
retval = inet_ntop(af, packed, ip, sizeof(ip));
^
3 errors detected in the compilation of
"./Modules/socketmodule.c".
gmake: *** [Modules/socketmodule.o] Error 2
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2003-10-23 12:25
Message:
Logged In: YES
user_id=6656
Just to be clear, please "attach" the build rather than
pasting it inline.
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-23 04:19
Message:
Logged In: YES
user_id=29957
Did you try 2.3.2 with the patch from the 2.3.2 build bugs page?
If it failed, please post the build log of the failing bit
to this bug.
----------------------------------------------------------------------
Comment By: Bill Baxter (billbaxter26)
Date: 2003-10-22 20:26
Message:
Logged In: YES
user_id=892601
Has there been any progress since August on getting
Python-2.3 to compile on IRIX 6.5? I really need to have
sockets working to use python.
----------------------------------------------------------------------
Comment By: Maik Hertha (mhertha)
Date: 2003-08-14 13:37
Message:
Logged In: YES
user_id=768223
I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m
on a FUEL 600Mhz.
The situation seems a little bit strange on this system. But
I have luck and get it compiled. As the current
implementation is not clean, my resolution also. Which
should be changed to get it work.
The manpage for gethostbyaddr_r says:
#include <sys/types>
#include <sys/socket>
#include <netinet/in.h>
#include <netdb.h>
So I included this in the __sgi-clause in socketmodule.c.
Looking in the header-files shows, that some variables are
defined if
#define _NO_XOPEN4 1
#define _NO_XOPEN5 1
are set, before the includes. This defines some more
variables, so that pyconfig.h should be changed.
#define HAVE_ADDRINFO 1
#define HAVE_SOCKADDR_STORAGE 1
Sure there are warnings about the redefinition of the
_(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests
don't fail. Also my applications run without exception or
coredump on FUEL, Octane, Octane 2.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-01 14:10
Message:
Logged In: YES
user_id=33168
Ralf, I will try to work on this, but it won't be for a week
or two probably. Can you tell me which machines (by name)
work and doesn't work. The only IRIX machine I seem to know
about it rattler.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-08-01 09:34
Message:
Logged In: YES
user_id=71407
For the records:
The Python2.3 (final) socket module still does not
compile under IRIX 6.5.20. It only compiles under 6.5.10.
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 20:07
Message:
Logged In: YES
user_id=31392
I applied a slight variant of Neal's patch and that seemed
to fix things. It still seems wrong that we define _SGIAPI,
but that will have to wait for 2.3.1.
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 15:54
Message:
Logged In: YES
user_id=31392
I learned a little about inet_ntop() in the last few
minutes. It looks like the size_t argument is an older
spelling, and the current POSIX says it should be socklen_t.
Regardless, it looks like we're using the new definition
when IRIX is actually providing the older definition.
Neal attached a patch that looks like it should clean up the
problem. Have you tried it? I think a better solution
would be to teach configure how to find inet_ntop() via
netdb.h, but that's probably too hard to get done in the new
couple of hours.
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 15:42
Message:
Logged In: YES
user_id=31392
There seem to be two causes of worry. The actual compiler
error in your build log and the use of _SGIAPI that
Casavanti warns again.
It looks like the compiler problems is because our
inet_ntop() prototype is wrong. That is Python says the
last argument is a socklen_t, but IRIX and Linux man pages
both say size_t. Perhaps size_t and socklen_t are different
sizes on IRIX, but not on Linux. What happens if you change
it to size_t?
The problematic code would appear to be these lines from
socketmodule.c:
#if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI
/* make sure that the reentrant (gethostbyaddr_r etc)
functions are declared correctly if compiling with
MIPSPro 7.x in ANSI C mode (default) */
#define _SGIAPI 1
#include "netdb.h"
#endif
It's the only use the _SGIAPI symbol that Casavant says we
shouldn't use. What happens if you remove the use _SGIAPI,
i.e. just make it
#if defined(__sgi) && _COMPILER_VERSION > 700
/* make sure that the reentrant (gethostbyaddr_r etc)
functions are declared correctly if compiling with
MIPSPro 7.x in ANSI C mode (default) */
#include "netdb.h"
#endif
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-17 02:27
Message:
Logged In: YES
user_id=71407
We have confirmed that the socket module in Python 2.3b1
and 2.3b2 fails to compile under these versions of IRIX:
6.5.10, MIPSpro 7.3.1.2m
6.5.19, MIPSpro 7.3.1.3m
6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge)
If Python 2.3 goes out without a working socket module it
will be useless for many people in science where IRIX is still
found quite frequently. Maybe even worse, we will also no
longer be able to advertise Python as a language that "runs
everywhere."
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-16 00:37
Message:
Logged In: YES
user_id=71407
Date: Tue, 15 Jul 2003 15:06:25 -0500
From: "Brent Casavant" <[EMAIL PROTECTED]>
To: "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]>
Subject: Re: IRIX & Python
Ralf,
I read through the sourceforge report. I don't have a
sourceforge
account so I didn't add there, but feel free to distribute my
ramblings.
First, they should be very careful about what version of the
operating system they are using. Real IPv6 support was only
added a few releases ago (6.5.20 I believe, though my
memory
is hazy). Some of the functions/macros corresponding to
IPv6
were introduced prior to that point, but implementation may
not have been complete. If they have to play tricks with
#define values to get a symbol recongnized it most likely
means that SGI didn't intend for that symbol to be used yet.
I suspect the problems they are seeing are because they are
using some version of IRIX 6.5.x that includes inet_ntoa()
definitions under _SGIAPI, but for which real support was
not yet complete. The namespace of symbols that begin
with a
single underscore and a capital letter is reserved for the OS
vendors, and the fact that someone is trying to manually
insert
a definition of _SGIAPI into the source should be a big red
warning flag.
That said, there is a correct method to deal with the new
capabilities of IRIX 6.5.x over time. This comes in two
parts. A better explanation is in /usr/include/optional_sym.h
First, when a new symbol is added to IRIX, the corresponding
header file will always have the following line in it:
#pragma optional some_new_symbol
The presence of this #pragma will cause the linker to not
complain if the symbol is missing when the executable is
linked. If SGI neglects to do so it is a bug that should
be reported to us.
The second part is that calls to these "optional" symbols
should be protected by a run-time check to see if the symbol
is actually present. Just like this:
#include <optional_sym.h>
#include <header_file_for_some_new_symbol.h>
. . .
if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) {
/* New function is present, use it */
qux = some_new_symbol(foo, bar, baz);
} else {
/* New function isn't present, do
something else */
qux = builtin_some_new_symbol(foo, bar,
baz);
}
This ensures that a single executable will be able to function
properly (or at least degrade gracefully) on all version of
IRIX 6.5.x. In other words you can compile on 6.5.20 and
run
on 6.5.8, or vice versa.
In particular, this means that compile-time detection of
features
such as inet_ntoa() is incorrect for IRIX 6.5.x -- these
decisions
should be made at run-time instead. If the decision is made
at
compile time the executable may well not execute on an older
version of IRIX 6.5.x. Unfortunately GNU configure is not
equipped
to utilize such advanced binary-compatability mechanisms,
so there's
no "easy" way to get GNU configure'd software to run across
all
IRIX 6.5.x releases, short of compiling only on the original
non-upgraded version of IRIX 6.5.
Hope that helps,
Brent Casavant
On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote:
> We are developing a Python-based (www.python.org)
application for
> IRIX. Until now the Python IRIX port was fully supported,
but the last
> two beta releases of Python (2.3b1 and 2.3b2) make me
increasingly
> worried because the crucial socket module (TCP/IP
sockets) fails to
> build. A while ago I've filed a bug report, but the Python
developers
> appear to be stuck:
>
>
https://sourceforge.net/tracker/?
func=detail&aid=728330&group_id=5470&atid=105470
>
> Is there a way to bring this to the attention of developers
at SGI to
> hopefully get some help?
>
> Thank you in advance!
> Ralf
>
--
Brent Casavant Silicon Graphics, Inc. Where am I? And
what am I
IRIX O.S. Engineer http://www.sgi.com/ doing in this
handbasket?
[EMAIL PROTECTED] 44.8562N 93.1355W 860F --
Unknown
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-06-30 16:21
Message:
Logged In: YES
user_id=71407
The socket module still fails to compile with Python
2.3b2, in addition to two other extensions. The full make
log is attached.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-05-22 08:47
Message:
Logged In: YES
user_id=21627
I think it would be best if detect presence of
inet_aton/inet_pton. Is IPv6 support possible on this
system? Then it would be best if that was detected, as well.
If it is not possible to detect aton/pton/ipv6, what is the
problem with not using them?
I'd like to have a look at the relevant headers (in
particular to understand the duplicate definition of
_SGIAPI), indeed.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 01:35
Message:
Logged In: YES
user_id=33168
Argh!!! This is a nightmare. The attached hack ^h^h^h
patch fixes the problem, but ...
_SGIAPI needs to be defined (~192 in socketmodule.c) in
order to get the prototypes for inet_aton, inet_pton. But
_SGIAPI can't be defined in the standard header files
because XOPEN_SOURCE is defined.
Martin, do you have any other suggestions? I don't see how
to do this right within configure. If you want I can send
you the header file(s).
----------------------------------------------------------------------
Comment By: alexandre gillet (gillet)
Date: 2003-05-12 19:41
Message:
Logged In: YES
user_id=150999
I had the same problem compiling socket on Irix.
We did find that on our system ENABLE_IPV6 is not define and
all the error are cause by that.
System that do not enable IPV6 are not well supported with
the socketmodule.c code.
We were able to compile socket after making few change in
the code:
I am not sure if I did it right but it compile.
I will post my patch but I do not see any place to attach my
file
example: See line 2794,2800
+ #ifdef ENABLE_IPV6
char packed[MAX(sizeof(struct in_addr),
sizeof(struct in6_addr))];
+ #else
+ char packed[sizeof(struct in_addr)];
+ #endif
I am not sure how to post the patch or file.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-05-05 20:44
Message:
Logged In: YES
user_id=71407
This is not in my area of expertise, but I've tried a couple of
(probably stupid) things:
#include <standards.h> in socketmodule.c instead of #define
_SGIAPI.
This resulted in even more errors.
./configure --disable-ipv6
Same errors as before.
I am lost here. Sorry. But you still have ssh access to
rattler.lbl.gov if that helps. Accounts for other Python developers
are a possibility.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 14:39
Message:
Logged In: YES
user_id=21627
Can you analyse these compiler errors in more detail,
please? What, in your opinion, is causing these problems,
and how would you correct them?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
