[ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the compile comman

SourceForge.net noreply at sourceforge.net
Tue May 23 11:13:45 CEST 2006


Bugs item #1491574, was opened at 2006-05-19 15:04
Message generated for change (Comment added) made by tknapen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Distutils
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


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

>Comment By: Toon Knapen (tknapen)
Date: 2006-05-23 11:13

Message:
Logged In: YES 
user_id=144552

Looking through the code of distutils I finally found that
plenty of information is recoved from the _current_
environment in distutils/sysconfig.py.

Thus the LDFLAGS env.var. I had defined when configuring
python is not stored somewhere. So when e.g. installing
numarray, I need to set the LDFLAGS env.var. again.

Would'nt it be better if python would store the
flags/options that were used to compile python itself. This
guarantees that the extension modules will be
compiled/linked with the same flags and guarantees a maximal
compatibility?

If you prefer to move this discussion to the python-ml ....

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

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-23 00:27

Message:
Logged In: YES 
user_id=21627

Something like that, yes. It's quite involved, so it is not
easy to see what the right approach is.

If you can come up with a patch that works for you, I can
review the patch to find out what else it breaks.

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

Comment By: Toon Knapen (tknapen)
Date: 2006-05-22 15:09

Message:
Logged In: YES 
user_id=144552

Indeed the -xcode=pic32 is not at fault here. The problem
though still is that distutils is not linking the shared
libraries using the link-option '-xarch=v9'. The linker
therefore complains about a mix of 32bit and 64bit code.

Should'nt distutils copy the content of LDFLAGS of when
python is being configured and add these options to the
link-line ?

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

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-20 08:31

Message:
Logged In: YES 
user_id=21627

You must be misunderstanding something. -xcode=pic32 does
*not* mean that the code ought to be compiled for the 32-bit
processor mode. Instead, it means that the PIC (position
independent code) offsets are encoded using 32-bit numbers,
which works for both 32-bit and 64-bit code as long as the
size of the code does not exceed 4GiB.

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

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


More information about the Python-bugs-list mailing list