Bugs item #970334, was opened at 2004-06-10 12:46
Message generated for change (Comment added) made by dlr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&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: Build
Group: Platform-specific
Status: Closed
Resolution: None
Priority: 5
Submitted By: JD Bronson (lonebandit)
Assigned to: Michael Hudson (mwh)
Summary: 2.3.4 fails build on solaris 10 - complexobject.c
Initial Comment:
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
----------------------------------------------------------------------
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 22:02
Message:
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,
----------------------------------------------------------------------
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 20:52
Message:
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
----------------------------------------------------------------------
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 19:52
Message:
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
----------------------------------------------------------------------
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 19:42
Message:
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
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-08-23 11:00
Message:
Logged In: YES
user_id=6656
Closing as threatened.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-08-07 21:43
Message:
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 :-)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-06-10 15:08
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
