This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: 2.3.4 fails build on solaris 10 - complexobject.c
Type: Stage:
Components: Build Versions:
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: mwh Nosy List: dlr, lonebandit, mwh, tim.peters
Priority: normal Keywords:

Created on 2004-06-10 12:46 by lonebandit, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (10)
msg21109 - (view) Author: JD Bronson (lonebandit) Date: 2004-06-10 12:46
this has been an ongoing issue:

gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o 
Objects/classobject.o Objects/classobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o 
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o 
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:469: error: invalid operands to 
binary ==
Objects/complexobject.c:469: error: wrong type 
argument to unary minus
Objects/complexobject.c:469: error: invalid operands to 
binary ==
Objects/complexobject.c:469: error: wrong type 
argument to unary minus
make: *** [Objects/complexobject.o] Error 1

..It fails at that point with no workaround.

Jeff
msg21110 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-06-10 15:08
Logged In: YES 
user_id=31435

See comments about Py_HUGE_VAL in pyport.h.  Possible 
that this platform defines C's HUGE_VAL incorrectly, in which 
case config for this platfrom needs to set Py_HUGE_VAL to a 
correct expansion.

You could also try compiling complexobject.c without 
optimization.  In at least one prior case, the platform 
HUGE_VAL was correct, but expanded to such a hairy 
expression that it confused the platform C compiler when 
optimization was cranked up.

Finally, you didn't say which version of gcc and its libraries 
you're using.  It's possible that another version would work.
msg21111 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-08-07 21:43
Logged In: YES 
user_id=6656

Given that this has sat here for two months without
activity, I propose closing it in another fortnight. 
Assigning to me on the off-chance this makes me more likely
to remember :-)
msg21112 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-08-23 11:00
Logged In: YES 
user_id=6656

Closing as threatened.
msg21113 - (view) Author: Daniel L. Rall (dlr) Date: 2005-12-19 19:42
Logged In: YES 
user_id=6606

I'm seeing this exact problem compiling Python 2.4.2 on
Solaris 10.  I've got the following gcc-related packages
installed:

SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49
SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49
SUNWgccruntime - runtime libraries (also?),
11.10.0,REV=2005.01.08.05.16

$ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL'
/usr/include/iso/math_c99.h:#undef      HUGE_VAL
/usr/include/iso/math_c99.h:#define     HUGE_VAL       
__builtin_huge_val

A quick look around didn't tell me what __builtin_huge_val
is defined to.  printf()'ing HUGE_VAL from a test.c proggie
shows the following:

e=0.000000e+00,
f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000
msg21114 - (view) Author: Daniel L. Rall (dlr) Date: 2005-12-19 19:52
Logged In: YES 
user_id=6606

Oops, forgot an arg -- HUGE_VAL is defined as the following
on Solaris 10:

e=Inf
f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000
msg21115 - (view) Author: Daniel L. Rall (dlr) Date: 2005-12-19 20:52
Logged In: YES 
user_id=6606

As noted by some other people on the web, defining
Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which
is defined as MAXFLOAT on Solaris), a successful compile can
be achieved.  If I explicitly #define Py_HUGE_VAL to
__builtin_huge_val, I get the same compilation error as
reported by this bug.  Removing optimization flags does not
help.  The HUGE_VAL provided by Solaris 10 doesn't seem to
be a workable value for pyport.h's macro.
 

My little test proggie was missing yet more args, so I'm
posting both the source and output this time.

--- snip ---
#include <math.h>

int main(char **argv)
{
#ifdef SOLARIS
    printf("SOLARIS=%e\n", SOLARIS);
#endif
    printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT);
    printf("HUGE: e=%e, f=%f\n", HUGE, HUGE);
    printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL);
}
--- snip ---

Output:

MAXFLOAT: e=3.402823e+38,
f=340282346638528859811704183484516925440.000000
HUGE: e=3.402823e+38,
f=340282346638528859811704183484516925440.000000
HUGE_VAL: e=Inf, f=Inf
msg21116 - (view) Author: Daniel L. Rall (dlr) Date: 2005-12-19 22:02
Logged In: YES 
user_id=6606

Issue #1276509 is a duplicate of this issue.  I've just
submitted a patch to the python-dev list for this problem,
which I'll attach below (and expect Tracker to mangle):

Index: configure.in
===================================================================
--- configure.in	(revision 41772)
+++ configure.in	(working copy)
@@ -215,6 +215,17 @@
   
 fi
 
+# See the #define for Py_HUGE_VAL in pyport.h.
+case $ac_sys_system/$ac_sys_release in
+  SunOS/5.10)
+    # Solaris 10's /usr/include/iso/math_c99.h defines
HUGE_VAL as
+    # __builtin_huge_val, which causes problems when
defining Py_HUGE_VAL.
+    AC_DEFINE(Py_HUGE_VAL, HUGE,
+              Define to a positive double which represents
infinity)
+    ;;
+esac
+
+
 #
 # SGI compilers allow the specification of the both the ABI
and the
 # ISA on the command line.  Depending on the values of
these switches,
msg21117 - (view) Author: JD Bronson (lonebandit) Date: 2005-12-19 22:12
Logged In: YES 
user_id=257991


This is too old to deal with any more. I had forgot I 
reported this. Using 2.4.2 under Solaris with Studio 11 
builds fine out of the box:

Python 2.4.2 (#1, Dec 12 2005, 19:14:42) [C] on sunos5

-JD
msg21118 - (view) Author: Daniel L. Rall (dlr) Date: 2005-12-19 22:19
Logged In: YES 
user_id=6606

But with Python 2.4.2 and GCC 3.4.2 (a perfectly reasonable
combination), the build does still fail on Solaris 10.
History
Date User Action Args
2022-04-11 14:56:04adminsetgithub: 40378
2009-03-20 22:12:30ajaksu2linkissue1276509 dependencies
2004-06-10 12:46:18lonebanditcreate