[2.7] bpo-11566: Extension build errors on Windows for _hypot

[thewtex]

This addresses C extension build errors related to an undefined _hypot
symbol when building with the Microsoft Visual C++ Compiler for Python
2.7 [1] or MinGWPy [2]. It also addresses errors when building a C++
extension with MinGWPy and C++11 from cmath, 'error "::hypot' has not
been declared'

On line 71 of PC/pyconfig.h, HAVE_HYPOT is defined, indicating that
hypot is expected to be available in current Windows toolchains.

[1] https://www.microsoft.com/en-us/download/details.aspx?id=44266

[2] https://mingwpy.github.io/

https://bugs.python.org/issue11566

[rgommers]

IIRC the MSVC hypot function is broken. I suggest you search the numpy codebase for HAVE_HYPOT; you'll see it's disabled for _MSC_VER < 1900 and reimplemented. That fix is well tested by now so possibly appropriate to just copy.

[thewtex]

@rgommers Thanks for the pointer.

I was able to find the NumPy _MSC_VER check:

https://github.com/numpy/numpy/blob/8d01ee40eb00160068cce3cb02c930cebf013230/numpy/core/src/private/npy_config.h#L36

and a discrepancy between the NumPy backup implementation and the CPython one:

https://github.com/numpy/numpy/blob/8d01ee40eb00160068cce3cb02c930cebf013230/numpy/core/src/npymath/npy_math_internal.h.src#L196-L202

cpython/Python/pymath.c

Line 35 in 3cc8259

double hypot(double x, double y)

but the existing MSVC hypot is used prior to this patch and is still used by this patch. It passes tests:

cpython/Lib/test/test_math.py

Lines 722 to 732 in 9dc2b38

	def testHypot(self):
	self.assertRaises(TypeError, math.hypot)
	self.ftest('hypot(0,0)', math.hypot(0,0), 0)
	self.ftest('hypot(3,4)', math.hypot(3,4), 5)
	self.assertEqual(math.hypot(NAN, INF), INF)
	self.assertEqual(math.hypot(INF, NAN), INF)
	self.assertEqual(math.hypot(NAN, NINF), INF)
	self.assertEqual(math.hypot(NINF, NAN), INF)
	self.assertRaises(OverflowError, math.hypot, FLOAT_MAX, FLOAT_MAX)
	self.assertTrue(math.isnan(math.hypot(1.0, NAN)))
	self.assertTrue(math.isnan(math.hypot(NAN, -2.0)))

When looking into replacing it, does not looks trivial -- Py_INFINITY needs to be defined. We would have to namespace the name to not conflict with hypot from math.h, ... Since that seems to be a different issue, I would rather just get this one in.

I was able to dig up an old VS 2008 to test this patch.

[c0yote]

I'm experiencing this problem with regard to mingw-w64 builds. Is this likely to be accepted?

[jdemeyer]

Also hitting this issue at sagemath/cysignals#76

[jdemeyer]

IIRC the MSVC hypot function is broken.

It doesn't matter whether hypot is broken is not. The problem here is that the #define hypot _hypot is breaking code which doesn't involve hypot at all. Simply including the C+ header <cmath> on Mingw64 causes compiler errors.

[jdemeyer]

@embray Do you happen to have the powers to merge this (or know a friend who does)?

[terryjreedy]

Closing and re-opening to trigger bedevere/news and appveyor CI

[terryjreedy]

If this is an issue for 3.x, we would normally patch master first and then backport.

[thewtex]

If this is an issue for 3.x, we would normally patch master first and then backport.

This is a 2.7-only issue.

[methane]

This is a 2.7-only issue.

Are you sure? master branch has same defines.
For MSVC, it is just a junk because we don't use VS2008 in the branch.
But for GCC, why this makes trouble for Python 2.7 but not 3.7?

Anyway, I prefer removing them in master branch.

[thewtex]

Here is the PR for master: #11283

This patch is significant for people that want to create Python C extensions with binary compatibility for Python 2.7 distributed by Python.org or many other sources. This requires Visual Studio 2008, the Microsoft Visual C++ Compiler for Python 2.7, or MinGWPy. MinGWPy is currently only available for Python 2.7. The patch for masterwill help MinGW-w64, but this has far less use compared to the official Python binaries.

[methane]

Thanks.

[thewtex]

@methane thanks for merging!!