BIND 10 #2026: detect Py_hash_t in ./configure and define it internally if not

[BIND 10 Development]

#2026: detect Py_hash_t in ./configure and define it internally if not
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  UnAssigned
            Priority:  high          |                       Status:  new
           Component:  build system  |                    Milestone:  Next-
           Sensitive:  0             |  Sprint-Proposed
         Sub-Project:  Core          |                     Keywords:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 From the commit log for 3da2b4d:
 {{{
 [master] use Py_hash_t for return value of tp_hash, and define it for old
 vers.

 The previous code (using long) caused build failure on Solaris.
 Python 3.2 changed the return type of internal hash API:
 http://docs.python.org/py3k/c-api/object.html#PyObject_Hash

 from long to Py_hash_t and solaris seems to be more strict about the
 difference of these types.
 }}}

 As noted in the log, that patch is a bit ad hoc (define it for older
 python versions referring to PY_MINOR_VERSION, and define it only for
 the libdns++ wrapper while in theory this can happen for other
 modules) for an urgent care fix.

 We should do it more cleanly: my suggestion is to detect the existence
 of Py_hash_t in ./configure and if not, define it (or introduce our
 internal type name) in some more commonly used header file.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2026>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development