Bugs item #995458, was opened at 2004-07-21 14:55
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce D. Ray (brucedray)
Assigned to: Nobody/Anonymous (nobody)
Summary: Does not build selected SGI specific modules
Initial Comment:
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?
----------------------------------------------------------------------
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-08-03 11:04
Message:
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.
----------------------------------------------------------------------
Comment By: Bruce D. Ray (brucedray)
Date: 2004-08-09 09:00
Message:
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.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 13:55
Message:
Logged In: YES
user_id=11375
So what exactly is the bug?
----------------------------------------------------------------------
Comment By: Bruce D. Ray (brucedray)
Date: 2004-07-30 10:00
Message:
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.
----------------------------------------------------------------------
Comment By: Terry J. Reedy (tjreedy)
Date: 2004-07-29 19:14
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
