[Python-bugs-list] [Bug #116255] 2.0b2: LDSHARED incorrect on SGI IRIX

[noreply@sourceforge.net]

Bug #116255, was updated on 2000-Oct-06 10:06
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2:  LDSHARED incorrect on SGI IRIX

Details: I think that's the problem.  But someone versed in Python Distutils will have to judge whether my fix is the right one.

NumPy 17.0 fails to build for me on 2.0b2 on IRIX 6.5.  This patch to the Python 2.0b2 installed tree fixes it and let's NumPy build correctly on IRIX.

config/Makefile:
-LDSHARED=       ld
+LDSHARED=       ld -shared $(LDFLAGS)

------------------------------------------------------------
Here is more detail on the error and the fix:

The NumPy build (for the latest version) fails on IRIX.

  cc -n32 -O ... 
  cc -n32 -O ... 
  ... 
  ld <list of .o's> -o build/lib.irix64-6.5-2.0/_numpy.so 

  ld: FATAL 12 : Expecting o32 objects:  
  build/temp.irix64-6.5-2.0/Src/_numpymodule.o is n32. 

There are two things failing the NumPy build. First, the ld invocation (in Distutils I assume) isn't specifying $LDFLAGS on the invocation line (which contains -n32), and second the ld invocation isn't specifying -shared.  The former is needed so the linker links a file with the same architecture as the source files it compiles; the latter is needed in order to build a shared object.

Thanks,

Randall



Follow-Ups:

Date: 2000-Oct-12 07:50
By: VizNut

Comment:
I just pulled and tested 2.0c1.  LDSHARED is not set correctly in this version either.  

This incorrect LDSHARED setting results in packages using Python's Makefile facility (PIL, DistUtils modules, etc.)  to fail when linking their shared object modules.

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

Date: 2000-Oct-12 09:26
By: gvanrossum

Comment:
Dear VizNut (what's your real name?), I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

I wonder what went wrong???

The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?
-------------------------------------------------------

Date: 2000-Oct-13 09:11
By: VizNut

Comment:
> Dear VizNut (what's your real name?), 

Hi Guido.  This is Randall Hopper.  I'm a somewhat infrequent poster to the list -- pretty busy with other things lately.  But I did want to make sure I helped test Python 2.

> I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

> The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

> The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?

Ahhh, that's it.  Thanks for explaining what it is doing.  Yes, on IRIX systems that support 64-bit addressing (all recent systems), uname -s returns "IRIX64".  On older systems, it returns "IRIX".  So when identifying IRIX, both should be accepted.

SGI should have come up with a better idea IMO, but then so should Microsoft with 64-bit Windows and "win32".

Just to be concrete, here is the output of the two command invocations you mentioned on modern SGI Octane and Onyx2 systems:

> uname -a
IRIX64 ralph 6.5 07201611 IP30
> uname -s
IRIX64

> uname -a
IRIX64 ethyl 6.5 07201611 IP27
> uname -s
IRIX64

Thanks in advance!

Randall


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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116255&group_id=5470