Issue970334
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.
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) * | 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) | 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) | 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:04 | admin | set | github: 40378 |
2009-03-20 22:12:30 | ajaksu2 | link | issue1276509 dependencies |
2004-06-10 12:46:18 | lonebandit | create |