| msg46138 - (view) |
Author: Michael Schloh von Bennewitz (michaesc) |
Date: 2004-06-08 08:48 |
| In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and Solaris 10 SPARC, this causes a build failure. I'm ashamed to say that I wasn't able to 100% diagnose this problem (I didn't have time). My first guess was that somehow HUGE_VAL was not getting properly defined on Solaris 10 due to its rewritten /usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL depending on a _STDC_C99 and _XOPEN_SOURCE definition). Because I noticed that the identifier HUGE is unconditionally defined on Solaris 10 and seemingly all earlier Solaris releases, I tried using that instead and the build problem disappeared. You can make your own conclusion as to whether my fix is correct, or if there is a better way to solve this problem. There may be a faulty assumption made by configure or in some Makefile of how the compiler is being used, or maybe python depends on a certain GCC release. CC: GCC 3.4.0 CXX: GCC 3.4.0 CFLAGS: -O2 -pipe CXXFLAGS: -O2 -pipe CPPFLAGS: None Make: GNU Make 3.80 LDFLAGS: None mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw checking MACHDEP... freebsd4 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no ... The OpenPKG Python package and patch: http://cvs.openpkg.org/dir?d=openpkg-src/python http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch Lots of luck, and thanks for maintaining Python. Regards, Michael, OpenPKG http://www.openpkg.org/ |
|
|
| msg46139 - (view) |
Author: Tim Peters (tim.peters) *  |
Date: 2004-06-08 19:02 |
| Logged In: YES user_id=31435 I don't see a reason to call this a Python bug. The C89 and C99 standards both require that math.h supply the HUGE_VAL macro. If the compilation system you're using doesn't do so, it's a bug in that system, and should be fixed there. Python doesn't ask for much, but does require an ANSI C compiler. |
|
|
| msg46140 - (view) |
Author: Hyeshik Chang (hyeshik.chang) * |
Date: 2004-07-17 14:05 |
| Logged In: YES user_id=55188 This doesn't look like a bug in Python per Tim's comment. (Reviewed by Seo Sanghyeon and me at KLDP CodeFest) |
|
|
| msg46141 - (view) |
Author: Chris P. Ross (cross) |
Date: 2004-12-23 17:43 |
| Logged In: YES user_id=12814 Hi. I found this today as well. However, a little research shows that what it's defined to (__builtin_huge_val) is actually a function pointer, not a number. So, if I changed Py_HUGE_VAL to be #def'd to HUGE_VAL(), it worked just find on my Solaris 10 machine. What does the c89 and c99 spec say that HUGE_VAL macro should be? A number? Or is having it be a function reference legal? |
|
|
| msg46142 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2004-12-23 18:09 |
| Logged In: YES user_id=31435 From C99: """ The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float. ... (footnote) HUGE_VAL, HUGE_VALF, and HUGE_VALL can be positive infinities in an implementation that supports infinities. """ Of course a function pointer is not "a positive double constant expression", so doesn't meet the standard's requirements. Some Googling suggested that the "-Xc or -Xa compliation options" may be needed to get standard behavior on Solaris, but that's just hearsay and I really have no idea. Reports of HUGE_VAL creating compilation problems on Solaris for other projects are also easy to find. |
|
|
| msg46143 - (view) |
Author: Chris P. Ross (cross) |
Date: 2004-12-23 18:40 |
| Logged In: YES user_id=12814 Oops. My bad. I failed to mention that I'm using gcc 3.4.x on Solaris 10. I assume those options are for the Forte suite (or whatever they're calling it now). Hmm. I wonder how to tell sun that they're header isn't compliant? I wonder if it fails in the same way with Forte? I should try to find out... It *is* a beta OS after-all. :-) Thanks! |
|
|
| msg46144 - (view) |
Author: Michael Hudson (mwh) |
Date: 2004-12-23 20:25 |
| Logged In: YES user_id=6656 Maaybe the parens are meant to be present in the macro definition? That would make some kind of sense, apart from probably still not meeting the letter of the standard (don't think the result of a function call is a "constant expression", somehow). |
|
|
| msg46145 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2005-02-10 03:45 |
| Logged In: YES user_id=21627 In GCC, __builtin_huge_val() is indeed a constant expression. The compiler just knows this function, and knows that the function call is indeed a constant expression. The compiler is entitled to that conclusion: __builtin_huge_val is a reserved name, and the compiler can associate any semantics with a reserved name (e.g. treat it as a keyword - just like sizeof(), which also yields a constant). (As a side note: you take the address of __builtin_huge_val, but that gives a linker error, as this function is nowhere implemented; the implementation of it in the compiler returns +INF) The header itself is certainly compliant - one just has to use the "right" compiler, i.e. Sun cc (aka SunPRO, aka Forte, aka whatever they're calling it now). Apparently, __builtin_huge_val is a constant (not a function) in Sun CC - and that is also standards compliant. I just remarked in #1116722 that this is a gcc bug, which should use its fixincludes magic to add the missing parentheses, or replace the definition of HUGE_VAL altogether with something else. Of course, the gcc bug shows only up if _XOPEN_SOURCE is defined (or _STDC_C99 or __C99FEATURES__) - otherwise, gcc will probably provide its own definition of HUGE_VAL. So it is likely that none of the gcc developers has noticed yet, as you need both Solaris 10 *and* a software that turns on _XOPEN_SOURCE. You might want to coordinate with casevh to report the gcc bug and come up with a patch, as outlined in #1116722. |
|
|