Expansion of NAN/HUGE_VAL is a function address on Solaris

[TCH68k]

I did

./configure --enable-optimizations --enable-shared ax_cv_c_float_words_bigendian=yes

and it failed with the error messages in the attached log.

The compiler is GCC 5.5.0 and configure set the C standard to C99, changing it to C11 in the Makefile did not help. Did i do something wrongly, or it just needs a later GCC?

Any help is much appreciated.

Linked PRs

• gh-136006: fix Py_NAN expansion on Solaris systems #136575

[TCH68k]

Solaris is not supported? Python's webpage said it should compile.

[ZeroIntensity]

Yeah, Solaris isn't an officially supported platform. See PEP 11 for the official list of supported platforms. AFAIK, recent versions support Solaris, but 3.9 is five years old at this point, and even if we wanted to fix it, 3.12 and older only get security fixes.

Are you able to compile on 3.13+? That's probably what the webpage is referring to.

[TCH68k]

I tried to compile 3.13.5. The configure worked, albeit it threw a warning:

configure: WARNING:

Platform "sparc-sun-solaris2.10" with compiler "gcc" is not supported by the
CPython core team, see https://peps.python.org/pep-0011/ for more information.

But the compiling does not even start at all, when i type make (it is gmake 4.4.1):

-c: -c: cannot open
-c: -c: cannot open
make: *** [Makefile:883: profile-run-stamp] Error 1

[ZeroIntensity]

What make and configure arguments did you use?

[TCH68k]

Same as i did for 3.9: --enable-optimizations --enable-shared ax_cv_c_float_words_bigendian=yes for configure and nothing for make.

[picnixz]

Py_HUGE_VAL is an __attribute__((const)) double (*)(void), because that's how Solaris defines them (see https://www.gnu.org/software/gnulib/manual/html_node/math_002eh.html):

The macros NAN and HUGE_VAL expand to a function address rather than a floating point constant on some platforms: Solaris 10.

Because of this, we can't perform artihmetic operations on it. The issue will always persist but I think we can maybe do something by changing it to -__builtin_huge_val() to get the negative HUGE_VAL.

However, there are likely to be other issues, especially if we're doing negative NaNs. So I don't think it's an easy task.