[Python-bugs-list] [ python-Bugs-764560 ] python treats IRIX64 and IRIX as different, but they are the

[SourceForge.net]

Bugs item #764560, was opened at 2003-07-02 13:38
Message generated for change (Comment added) made by gmlack
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764560&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Gordon Lack (gmlack)
Assigned to: Martin v. Löwis (loewis)
Summary: python treats IRIX64 and IRIX as different, but they are the

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Gordon Lack (gmlack)
Date: 2003-07-11 12:12

Message:
Logged In: YES 
user_id=88015

   I thought I had checked the box - I'll try again....

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-07-10 21:47

Message:
Logged In: YES 
user_id=21627

There is no attachment. Can you please check the checkbox?

----------------------------------------------------------------------

Comment By: Gordon Lack (gmlack)
Date: 2003-07-09 14:14

Message:
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.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-07-05 17:32

Message:
Logged In: YES 
user_id=21627

Would you like to work on a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764560&group_id=5470