[Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] (original) (raw)

SourceForge.net noreply at sourceforge.net
Fri Feb 11 07:03:11 CET 2005

Patches item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Comment added) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470

Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. Löwis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.]

Initial Comment: This is a duplicate of 970334.

The fix I used was to make the following change in pyport.h:

Change #define Py_HUGE_VAL HUGE_VAL

to

#define PY_HUGE_VAL DBL_MAX.

DBL_MAX is found in float.h

Versions used:

Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release.

Comment By: Case Van Horsen (casevh) Date: 2005-02-10 22:03

Message: Logged In: YES user_id=1212585

I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read:

#define HUGE_VAL __builtin_huge_val()

The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun.

Comment By: Case Van Horsen (casevh) Date: 2005-02-10 21:16

Message: Logged In: YES user_id=1212585

I ran mkheaders to rebuild the gcc headers but that made no difference.

The following program (hv.c) compiled correctly:

#define _XOPEN_SOURCE 500 #include <math.h> int main() { double f=HUGE_VAL; }

The following program (hv2.c) did not compile.

#define _XOPEN_SOURCE 1000 #include <math.h> int main() { double f=HUGE_VAL; }

Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $

I have attached hv.i and hv2.i. I have also attached complexobject.i

I'm not a C programmer so please let me know what else I can do to help.

Comment By: Case Van Horsen (casevh) Date: 2005-02-10 08:50

Message: Logged In: YES user_id=1212585

I tried steps 1 through 4 and it fails, with and with the ().

I'm not sure how to do step 5.

I will try the short program snippet later and report back.

Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:44

Message: Logged In: YES user_id=31435

Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly.

Comment By: Martin v. Löwis (loewis) Date: 2005-02-09 19:23

Message: Logged In: YES user_id=21627

I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery.

It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using

#define HUGE_VAL __builtin_huge_val

The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read

#define HUGE_VAL __builtin_huge_val()

So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h.

I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please,

  1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h
  2. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val
  3. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program

#include <math.h> int main() { double f=HUGE_VAL; }

fails on Solaris 10. For that report

  1. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system.

  2. Report the gcc bug number and the patch in this report.

Comment By: Tim Peters (tim_one) Date: 2005-02-09 17:43

Message: Logged In: YES user_id=31435

The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too.
#define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK.

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

More information about the Patches mailing list