[Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors
SourceForge.net
noreply@sourceforge.net
Wed, 16 Jul 2003 17:27:50 -0700
Bugs item #728330, was opened at 2003-04-27 02:21
Message generated for change (Comment added) made by rwgk
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: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: IRIX, 2.3b1, socketmodule.c compilation errors
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: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-16 17: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-15 15:37
Message:
Logged In: YES
user_id=71407
Date: Tue, 15 Jul 2003 15:06:25 -0500
From: "Brent Casavant" <bcasavan@sgi.com>
To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com>
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?
bcasavan@sgi.com 44.8562N 93.1355W 860F --
Unknown
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-06-30 07: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-21 23: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-21 16: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 10: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 11: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 05: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