System is SGI R10K running Irix 6.5.15
Compiler is MIPSpro 7.3

Default configuration build sequence works and installs
a python
2.3.4 that does not support GL, audio, etc. because the
SGI specific
modules for those are not built in the default
configuration.  To
quote the README:

     On SGI IRIX, there are modules that interface to
many SGI
     specific system libraries, e.g. the GL library and
the audio
     hardware.  These modules will not be built by the
setup.py
     script.

Therefore, after the default configuration build and
install, I
uncommented the lines in Modules/Setup that read:

     gl glmodule.c cgensupport.c -I$(srcdir) $(GLHACK)
-lgl -lX11
     fm fmmodule.c $(GLHACK) -lfm -lgl
     sgi sgimodule.c
     al almodule.c -laudio
     cd cdmodule.c -lcdaudio -lds -lmediad
     cl clmodule.c -lcl -lawareaudio
     fpectl fpectlmodule.c -lfpe
     fpetest fpetestmodule.c

I then did a  make clean   followed by   make

Errors returned were:

         cc   -o python \
                        Modules/python.o \
                        libpython2.3.a -ldl  -lpthread
-lmpc   -lm  
ld32: WARNING 84 : /usr/lib32/libdl.so is not used for
resolving any symbol.
ld32: WARNING 84 : /usr/lib32/mips4/libmpc.a is not
used for resolving any symbol.
ld32: ERROR   33 : Unresolved text symbol "initgl" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initfm" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initsgi" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "inital" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initcd" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initcl" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.
ld32: ERROR   33 : Unresolved text symbol "initfpectl"
-- 1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.   
ld32: ERROR   33 : Unresolved text symbol "initfpetest"
-- 1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.    
ld32: INFO    152: Output file removed because of error.
*** Error code 2 (bu21)


A previous message on the build said that I would have
to rerun
make   Therefore, I again did a  make clean   followed
by make
and got the error message:

     don't know how to make glmodule.c


How is this build to be done?

Logged In: YES 
user_id=593130

The appropriate place for how-to questions is 
comp.lang.python and the corresponding mailing list.  Please 
consider closing this until you are fairly sure you have found a 
bug in the distribution itself.

Logged In: YES 
user_id=1063363

Would that be something like the message
(<http://groups.google.com/groups?q=author:Bruce+author:D.+author:Ray&hl=en&lr=&ie=UTF-8&scoring=r&as_drrb=b&as_mind=1&as_minm=7&as_miny=2004&as_maxd=30&as_maxm=7&as_maxy=2004&selm=spamtrap-1507041215070001%40physics.nmr.iupui.edu&rnum=1>)
I posted to comp.lang.python 15 Jul. 2004?

I posted that back before I managed to tease out of the various
convolutions of the build hints that there might be a
problem in the
construction of a Makefile that points the build to the
wrong directory.
As hinted at in that article, I had already done a search of
the publicly
available documentation on python (actually several searches
including
a download and grep of these).  I also did searches of
comp.lang.python for anything related to SGI, Silicon
Graphics, or
Irix; and of comp.sys.sgi.* for anything related to python
(if you wish
to reproduce this, you might want to exclude the strings
"dat" and
"tape" because of the many queries there on how to use a
Python brand
drive for archiving).

By 21 Jul. 2004, when I opened this, I was persuaded that I
have found
a bug in the build, or at least a deficiency in the
documentation for
build and install.

I believe that I have found a bug in the distribution with
respect to
building on SGI with MIPSpro 7.3 compilers a python with support
for available SGI functionality.  Thank-you kindly for your
reply, but
I really am reporting what appears to be a bug. 
Accordingly, I will
leave this open.

Logged In: YES 
user_id=11375

So what exactly is the bug?

Logged In: YES 
user_id=1063363

I believe I have listed a bug in the build and what would
appear to be a problem in documentation as well.  These
are:

1. When the lines listed previously in Modules/Setup for
   SGI specific modules are uncommented, there appears
   to be a problem in the construction of the Makefile that
   points the build away from the SGI specific modules to
   be built.  The result of this is a total failure to build
   python 2.3.4 with SGI specific modules with error
   messages as given previously.

2. Documentation on the general issue of use of
   Modules/Setup to build modules not otherwise built
   is not adequate.

Logged In: YES 
user_id=11375

The makesetup script special-cases the glmodule.c file
(around line 214); this is responsible for "don't know how
to make glmodule.c".  Presumably at one point the glmodule.c
file would always be regenerated.

I still have no idea why linking fails.

I suspect this can be closed either as "won't fix" or "out of date".

While only Irix 4 and not Irix 6 is listed in
Removing support for little used platforms
http://www.python.org/dev/peps/pep-0011/
I suspect Irix 6 may be close to that stage.  I asked on pydev.

In any case, Irix modules are gone in Py3
http://www.python.org/dev/peps/pep-3108/#irix

Guido's answer: "Irix is long dead and we don't support it in any form
or version."