[Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.]
SourceForge.net
noreply at sourceforge.net
Wed Jun 22 16:47:28 CEST 2005
Patches item #1116722, was opened at 2005-02-05 18:02
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&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: 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: Anthony Baxter (anthonybaxter)
Date: 2005-06-23 00:47
Message:
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...
----------------------------------------------------------------------
Comment By: Case Van Horsen (casevh)
Date: 2005-03-19 17:06
Message:
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.
----------------------------------------------------------------------
Comment By: Case Van Horsen (casevh)
Date: 2005-03-05 09:28
Message:
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 at 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 at 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.
>
----------------------------------------------------------------------
Comment By: Case Van Horsen (casevh)
Date: 2005-03-05 09:26
Message:
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 at 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 at 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.
>
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-05 06:04
Message:
Logged In: YES
user_id=21627
Turns out casevh's report is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-05 01:18
Message:
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
----------------------------------------------------------------------
Comment By: Case Van Horsen (casevh)
Date: 2005-02-11 17:33
Message:
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.
----------------------------------------------------------------------
Comment By: Case Van Horsen (casevh)
Date: 2005-02-11 17: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-11 16: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-11 03: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-10 15: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-10 14: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 <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.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2005-02-10 12: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