This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: python treats IRIX64 and IRIX as different, but they are the
Type: Stage:
Components: Build Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: loewis Nosy List: gmlack, loewis
Priority: normal Keywords:

Created on 2003-07-02 12:38 by gmlack, last changed 2022-04-10 16:09 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
configure.diffs gmlack, 2003-07-11 11:12 Patch for configure
Messages (6)
msg16811 - (view) Author: Gordon Lack (gmlack) Date: 2003-07-02 12:38
Related to bug 216255 (116255?), but this goes deeper,
as it refers to
the *running* of python rather than just its building.

If I build python on an Irix6.5 system (that is
new/large) the tag
"irix646" is used in the build/temp.* directory (and
Lib/plat-*).

This has several effects:

a) the plat-irix6 directory from the standard
distribution is ignored.

b) running the tests on an IRIX system after compiling
on an IRIX64 one
   causes it to rebuild everything, as it will look for
   temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/
rather than the
   temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which
were actually built.

c) running the same executable on a smaller system (a
single
   installation, NFS mounted onto a large number of
systems, for
   which "uname -s" returns IRIX, not IRIX64) will
cause it to fail
   to find the <<prefix.>/python2.2/Lib/plat-irix646
directory.
   (This might also affect 3rd party module
installation?).



   IRIX and IRIX64 are the same when you build n32
binaries (which is
what is built by default).  Python should treat them
the same.

   It should be possible to *configure* this OS tag at
configure time
(which would avoid this problem).

   Also, installing the "plat-irix646" directories
under <<exec-prefix>>
rather than <<prefix>> would remove the need for such a
tag in the
installed files.
msg16812 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-05 16:32
Logged In: YES 
user_id=21627

Would you like to work on a patch?
msg16813 - (view) Author: Gordon Lack (gmlack) Date: 2003-07-09 13:14
Logged In: YES 
user_id=88015

   Ok - to fix this *particular* part of the problem turns
out to be
simple.  (I had tried setting MACHDEP in my environment, but
that fails
as, if MACHDEP is set, then the configure script does not
set
ac_sys_system and ac_sys_release so tests on these fail to
get done).

   So, attached is the patch which equates the two.


   NOTE: There are other build problems.  The SGI C linker
(and OSF1)
uses -rpath not -R, and the extension buuilding scripts
don't knwo how
to handle this...but I suppose these would be for a
different bug 
report.
msg16814 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-10 20:47
Logged In: YES 
user_id=21627

There is no attachment. Can you please check the checkbox?
msg16815 - (view) Author: Gordon Lack (gmlack) Date: 2003-07-11 11:12
Logged In: YES 
user_id=88015

   I thought I had checked the box - I'll try again....
msg16816 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-13 09:49
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

configure 1.414
configure.in 1.425
configure 1.279.6.21
configure.in 1.288.6.21
History
Date User Action Args
2022-04-10 16:09:38adminsetgithub: 38772
2003-07-02 12:38:01gmlackcreate