Compile snags on AIX & IRIX

Donn Cave donn at u.washington.edu
Fri Aug 11 13:57:12 EDT 2000


Quoth Art Haas <arthur.haas at westgeo.com>:
| I've hit snags on both these platforms with Python-1.6b1. I sent in a
| patch yesterday for an easy workaround on AIX, but I stumbled across
| another glitch on AIX.
|
| xlc -qarch=pwr3  -O2 -qmaxmem=-1 -I../../Modules/../Include -I.. -DHAVE_CONFIG_H -c ../../Modules/socketmodule.c
| "/usr/include/sys/socket.h", line 76.21: 1506-247 (S) Incompatible type specifier "int".
| make[1]: *** [socketmodule.o] Error 1
| make[1]: Leaving directory `/omega/1.8.1/rel/wgc/python.1.6/src/Python-1.6b1/pwr3/Modules'
| make: *** [Modules] Error 2
|
| What happens is in `config.h' we get this ...
|
| -- /* Define to `int' if <sys/types.h> doesn't define.  */
| #define socklen_t int
|
| ... so things move along until we try to compile the socket
| module. Once <sys/socket.h> gets picked up, we get this line ...
|
| typedef __ulong32_t socklen_t;
|
| which gets preprocessed into
|
| typedef __ulong32_t int;
|
| then the compile fails.
|
| The workaround I had was to simply comment out the `#define' from
| config.h and start the compile again ...

[... IRIX stuff ...]

| I'm curious to see if others have seen similar behavior. I'm on AIX 4.3.2,
| IRIX 6.5. 

Your analysis of the socklen_t problem looks right to me.  I have it
in /usr/include/sys/socket.h on AIX 4.3.3, but not in 4.2.0.  It's also
in sys/socket.h on FreeBSD 4.0.  The configure script however looks for
it only in <sys/types.h>;  if you add <sys/socket.h> to its little test
program, it will find it.  That's probably safe for everyone, but there's
an outside chance someone has socklen_t in <sys/types.h> but has no
<sys/socket.h> and it will go wrong for them.

It's a miserable history of problems.  A few years back, it seems to me
everyone defined these parameters as "int", following Berkeley practice.
Then under the influence of an X/Open standard they started switching to
"unsigned int".  (You can tell this is a standards body at work, because
they appear to have no idea what unsigned arithmetic is good for in C.)
Naturally a program that has to compile under both regimes has a problem,
especially when the compiler won't tolerate that type mismatch.  Eventually
this must have come to the attention of the standards bodies, and now we
have socklen_t.  But of course, as a typedef that the preprocessor can't
use as a condition, so as far as I can see it's no help whatever, because
of course the old "int" platforms don't have it and you can't notice that
in the preprocessor.  socklen_t looks to me like a non-portable synonym
for unsigned int.

Unfortunately, the preprocessor logic I use for this one depends on
_XOPEN_SOURCE_EXTENDED,  and it doesn't literally work everywhere,
it just works for me where the compiler cares enough that it matters.

The WCHAR_T problem you ran into doesn't have anything to do with AIX,
that I can see, it's really a source error.  unicodeobject.h probably
should leave thost macros to config.h.  I would assume people have been
reporting these things as bugs, except I'm not sure whom you'd report
a 1.6 bug to, having fallen behind on the intrigues.

	Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list