I've compiled / linked Python 2.2.2 on Solaris 2.6 for 
both of my Solaris releases (Solaris 2.6 & Solaris 8).  
Python works fine on Solaris 2.6; however, on Solaris 
2.8 I get the following:

  File "/usr/local/lib/python2.2/SocketServer.py", line 
340, in server_bind
    self.socket.bind(self.server_address)
  socket.gaierror: (3, 'getaddrinfo failed')

Solaris 2.6 does not have getaddrinfo but Solaris 8 
does.  The failure occurs on Solaris 8 because Python 
finds getaddrinfo in /usr/lib/libsocket.so 
before /usr/local/lib/python2.2/lib-dynload/_socket.so.  
The return code of 3 (EAI_BADFLAGS) is a result of 
ai_flags mismatch:

  bsqa1.nyc:/u/woodd > grep 'define.AI_PASSIVE' 
Python-2.Modules/addrinfo.h
  #define AI_PASSIVE      0x00000001 /* get address to 
use bind() */

  bsqa1.nyc:/u/woodd > 
grep 'define.AI_PASSIVE' /usr/include/netdb.h
  #define AI_PASSIVE      0x0008  /* intended for bind() 
+ listen() */

The enclosed patch is simple: always "#define 
getaddrinfo fake_getaddrinfo" if we don't have 
getaddrinfo.  The same applies for getnameinfo.  The 
enclosed patch is against v2.2.2 Modules/addrinfo.h.  
David

Logged In: YES 
user_id=21627

I'm not sure I want to support this. Shouldn't you build two 
installations of Python instead?

Logged In: YES 
user_id=62760

Let me ask a hypothetical (and admittedly facetious) 
question - if I had Solaris 2.5.1, 2.6, 7, 8, 9 would I need to 
maintain 5 installations of Python?  Seriously though, I don't 
think it's unreasonable to expect backwards compatibility.  
Sun promises to deliver operating systems such that any 
piece of code compiled/linked on Solaris 2.6 for example will 
run without modification on Solaris 7, 8, 9, etc.  If Python is 
going to break after Solaris release upgrades I'd rather not 
have it on my systems at all.

Of the 300+ packages I have compiled/installed in /usr/local 
only 5 (sysinfo, scsiinfo, lsof, etc) require version specific 
installations.  Notice Perl is not in that list ;-).  The version 
specific installations are warranted as these packages 
operate at a very low level (directly with hardware device 
drivers).  Python operates at a very high level using fairly 
standard library calls; therefore, this really shouldn't be 
necessary.  

David

Logged In: YES 
user_id=21627

Apparently, Sun cannot deliver what it promises: Here we
have a piece of software built for Solaris 2.6 which breaks
on later versions.

In general, I think Python cannot guarantee that this won't
happen again: There might always be the need to emulate some
function not available on a certain operating system which
then gets added in later releases of the operating system,
in an incompatible fashion. 

I cannot even guarantee that this doesn't happen for your
specific installation if the problem at hand is solved, and
I think there is a chance that some of the 300+ packages
show the same problem, and you just haven't noticed yet.

In any case, I'll consider the patch for inclusion after 2.3b1

Logged In: YES 
user_id=62760

> Apparently, Sun cannot deliver what it promises: Here we
> have a piece of software built for Solaris 2.6 which breaks
> on later versions.

Haha - you have me there :-).

> In general, I think Python cannot guarantee that this won't
> happen again: There might always be the need to emulate
> some function not available on a certain operating system 
> which then gets added in later releases of the operating 
> system, in an incompatible fashion. 

I would never ask for a guarantee; however, would it be too 
much to ask that well know public interfaces such 
as getaddrinfo() be emulated with not so well known internal 
names?  I wasn't the one who invented fake_getaddrinfo 
afterall - look at socketmodule.c (line 230 v2.2.2 MAC OS X).

> I think there is a chance that some of the 300+ packages
> show the same problem, and you just haven't noticed yet.

Unlikely.

> In any case, I'll consider the patch for inclusion after 2.3b1

Thanks.  David

Logged In: YES 
user_id=21627

The patch in this form is insufficient; there are more
functions that may clash if a getaddrinfo suddenly appears.
I have committed a similar patch as socketmodule.c 1.261.

As for whether there are other occurrences of that problem:
it is asked too much to review the code base in this
respect. However, feel free to submit patches correcting
further occurrences if you find any.