Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections.

Python 2.5, Solaris x86 10 Update 3, Sun Studio 11

xcode=pic32 option is not supported on Solaris x86 Sun C  . Python's ./configure script on Solaris systems sets the
compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC.

Perhaps I was unclear in bug #1561333 that this resulted in only a warning.  Actually the build will fail because of the incorrect flag.

One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15).

So I think a patch should be architecture-specific. Can somebody come up with a patch that does that?

While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine.

If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either.

I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all.

I'm willing to take a stab at a patch.  I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are:

Sun cc Sparc: -xcode=pic32
Sun cc X86: -Kpic

Does that match the way you read it, loewis?

Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See

http://blogs.sun.com/x86be/category/Sun

According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit.  In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both?

The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well.

I've made a patch for configure.in to fix this bug.  There are two notes to explain why it was written the way it is:

The first problem is to determine which processor type we are using.  'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems.  There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior.

The second choice is how to handle the default case if the result of the above is neither sparc or i386.  I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses.  My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc.  I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic.

This patch is a diff against Python 2.5's configure.in file.  I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed.  I don't have a 64-bit x86 system to test against.  The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail.  This is a known problem covered by other bug reports which I believe is unrelated to this patch.

I couldn't find the option to upload a file, so here is the patch inline:

---snip---
*** configure.in.old    2007-03-11 23:01:16.879612000 -0700
--- configure.in        2007-03-11 23:31:48.098734000 -0700
***************
*** 1543,1551 ****
  then
        case $ac_sys_system/$ac_sys_release in
        SunOS*) if test "$GCC" = yes;
!               then CCSHARED="-fPIC";
!               else CCSHARED="-xcode=pic32";
!               fi;;
        hp*|HP*) if test "$GCC" = yes;
                 then CCSHARED="-fPIC";
                 else CCSHARED="+z";
--- 1543,1553 ----
  then
        case $ac_sys_system/$ac_sys_release in
        SunOS*) if test "$GCC" = yes;
!               then CCSHARED="-fPIC";
!               elif test `uname -p` = sparc;
!               then CCSHARED="-xcode=pic32";
!               else CCSHARED="-Kpic";
!               fi;;
        hp*|HP*) if test "$GCC" = yes;
                 then CCSHARED="-fPIC";
                 else CCSHARED="+z";
---snip---

The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK.

Thanks for the patch. Committed as r54283 and r54284.

The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK.

I won't apply the patch to the 2.4 branch, as that branch is not actively maintained anymore.

Sorry, not sure where the duplicate comment came from.  That was just an FYI anyways.  I'm fine with the fix only coming out in the 2.5 branch.