[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: Build
Status: Closed
Resolution: Invalid
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


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

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

Comment:
To help track this, I started picking through configure and references related to uname.  I found through experimentation that this variable in my Python build script environment:

setenv MACHDEP irix646

was preventing LDSHARED from being set correctly by configure.  I had been setting this with Python thus far because Python installs object files in a directory under $PREFIX with this $MACHDEP string in a directory name, and $MACHDEP is set differently based on whether this is an IRIX or an IRIX64 system, regardless of the compile architecture settings (you can compile code for IRIX on an IRIX64 system via -o32 and -n32). 

Even when building for the same architecture, generating the same object files, it would install in a different subdirectory name based on $MACHDEP on different systems.

Unsetting this variable allows LDSHARED to be set correctly.  It's a work-around for now at least.

Thanks for the help.  If you'd like, we can close this bug out.  And later if I come up with a patch to fix the "different install directory" problem (if I find it's still needed with Python2), I'll open another PR.

Thanks,

Randall





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

Date: 2000-Oct-13 09:56
By: gvanrossum

Comment:
If I understand this correctly, it was a user error (set MACHDEP in environment).

Closing.

Thanks for your patience, Randall!
-------------------------------------------------------

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