Issue1116722
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 2005-02-05 07:02 by casevh, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
hv2.i | casevh, 2005-02-11 05:16 | |||
hv.i | casevh, 2005-02-11 05:16 | |||
complexobject.i | casevh, 2005-02-11 05:17 |
Messages (22) | |||
---|---|---|---|
msg47663 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-02-05 07:02 | |
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. |
|||
msg47664 - (view) | Author: Tim Peters (tim.peters) * | Date: 2005-02-10 01:43 | |
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. |
|||
msg47665 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2005-02-10 03:23 | |
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 <install>/include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit <install>/include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. 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 - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. 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. 7. Report the gcc bug number and the patch in this report. |
|||
msg47666 - (view) | Author: Tim Peters (tim.peters) * | Date: 2005-02-10 04:44 | |
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. |
|||
msg47667 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-02-10 16:50 | |
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. |
|||
msg47668 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-02-11 05:16 | |
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. |
|||
msg47669 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-02-11 06:03 | |
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. |
|||
msg47670 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-02-11 06:33 | |
Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in <install>/include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. |
|||
msg47671 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2005-03-04 14:18 | |
Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 |
|||
msg47672 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2005-03-04 19:04 | |
Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 |
|||
msg47673 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-03-04 22:26 | |
Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * <martin@v.loewis.de> to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein <chrisw@pobox.com> * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include <math.h> int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > |
|||
msg47674 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-03-04 22:28 | |
Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * <martin@v.loewis.de> to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein <chrisw@pobox.com> * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include <math.h> int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > |
|||
msg47675 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-03-19 06:06 | |
Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. |
|||
msg47676 - (view) | Author: Anthony Baxter (anthonybaxter) | Date: 2005-06-22 14:47 | |
Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... |
|||
msg47677 - (view) | Author: Bill Clarke (slashlib) | Date: 2005-06-23 04:54 | |
Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. |
|||
msg47678 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-06-23 05:35 | |
Logged In: YES user_id=1212585 "make testall" fails with an error in _curses: missing typeahead(). I don't know it that is normal or not. I will try some additional tests this weekend, including using the new iso/math_c99.h file. A more subtle issue is that some of the the Solaris Express releases identified themselves as 5.10.1 and the latest Solaris Express (and I believe OpenSolaris) identify themselves as 5.11 and will probably use 5.11.x in the future. I will try to upgrade to the latest Solaris Express release this weekend and report how that behaves. |
|||
msg47679 - (view) | Author: Bill Clarke (slashlib) | Date: 2005-06-23 06:50 | |
Logged In: YES user_id=421902 i should clarify my comments, the thing that was recently fixed in gcc is the HUGE_VAL problem, not the XOPEN_SOURCE problem. note: an easy test for the XOPEN_SOURCE problem with g++ is: """ #include <Python.h> #include <cwchar> """ |
|||
msg47680 - (view) | Author: Bill Clarke (slashlib) | Date: 2005-06-23 08:10 | |
Logged In: YES user_id=421902 to fix the XOPEN_SOURCE problem on Solaris 10 (and hence to be able to compile python modules with g++) you must _not_ define _XOPEN_SOURCE_EXTENDED. XOPEN_SOURCE must be 500 as well. here's a patch for configure.in for the XOPEN_SOURCE_EXTENDED change: """ --- configure.in~ 2005-03-29 09:23:34.000000000 +1000 +++ configure.in 2005-06-23 18:00:39.596747000 +1000 @@ -198,8 +198,15 @@ # definition of _XOPEN_SOURCE_EXTENDED and _POSIX_C_SOURCE, or else # several APIs are not declared. Since this is also needed in some # cases for HP-UX, we define it globally. - - AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) + # except for Solaris 10, where it must not be defined! + case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + ;; + *) + AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, + Define to activate Unix95-and-earlier features) + ;; + esac AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEEE Stds 1003.1-2001) """ this fix (along with _XOPEN_SOURCE == 500) means i can compile python modules with g++ now. yay! also note: Solaris 10's feature_tests header will override the setting of _POSIX_C_SOURCE (to 199506L) since _XOPEN_SOURCE is 500. from my reading, _POSIX_C_SOURCE should only be 200112L if _XOPEN_SOURCE is 600, so perhaps the _POSIX_C_SOURCE define should also be disabled for Solaris 10 (although this will make no material difference usually). |
|||
msg47681 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2005-06-26 18:33 | |
Logged In: YES user_id=21627 For the specific bug reported in this report (Py_HUGE_VAL HUGE_VAL), I would like to close this as a third-party bug, and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. However, it appears that the original problem (of g++ pre-defining _XOPEN_SOURCE) also persists. So we just extend the existing configure test to 5.10. slashlib: this bug is only about the HUGE_VAL problem. If additional problems exist, please report them in a separate report. |
|||
msg47682 - (view) | Author: Bill Clarke (slashlib) | Date: 2005-06-27 00:38 | |
Logged In: YES user_id=421902 >For the specific bug reported in this report (Py_HUGE_VAL > HUGE_VAL), I would like to close this as a third-party bug, > and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. sounds fine to me, except neither of those versions have been released yet (-: > slashlib: this bug is only about the HUGE_VAL problem. If > additional problems exist, please report them in a separate > report. my apologies. new bug report is 1227966 <https://sourceforge.net/tracker/index.php?func=detail&aid=1227966&group_id=5470&atid=305470> |
|||
msg47683 - (view) | Author: Case Van Horsen (casevh) | Date: 2005-06-28 05:43 | |
Logged In: YES user_id=1212585 GCC 3.4.3 is shipped with Solaris 10. I think it would be unfortunate to mandate GCC 3.4.5 or 4.0.1. At my real job, requiring a different version of GCC would be unacceptable. Comments in the README file documenting the problem and listing the word-arounds would be acceptable. I would be willing to write a draft version of the comments. BTW, OpenSolaris and the latest Solaris Express releases from Sun report the OS version as 5.11 and still come with GCC 3.4.3. Some intervening versions report themselves as 5.10.1. Sun's Studio 10 compiler is available for free for use with OpenSolaris and it does compile python properly as is. |
|||
msg47684 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2005-11-26 11:40 | |
Logged In: YES user_id=21627 This is now fixed as a side effect of 41546 and 41545: _XOPEN_SOURCE is restricted to 500 on Solaris 10, causing math_c99.h not to be used. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:09 | admin | set | github: 41528 |
2005-02-05 07:02:43 | casevh | create |