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