Michael A. Cleverly reports on comp.lang.tcl:
#if (TCL_MAJOR_VERSION == 8) && (TCL_MINOR_VERSION >= 4) #define Tcl_InitHashTableEx(x, y, z) Tcl_InitCustomHashTable(x, y, z) #endifwas needed to compile Ck.MC (17 July): Actually in retrospect it was only needed because I was building with genkit (to build a tclkitck). Ck itself has been updated by its maintainer for Tcl 8.4 at all yet, though it does compile and run fine. ./configure must have found my 8.4a2 sources but the 8.4b1 header files (?). Sorry for any confusion. :-)
So, apparently Ck was written to the interface of Tcl 8.4a2? It should be updated to use the interface of Tcl 8.4b1. As noted below, the name changed during alpha development.
From the tcl ChangeLog:
2001-01-18 Andreas Kupries <[email protected]> * Everything below belongs together, it fixes bug #123153. * generic/tcl.h (line 342): A bit more explanation about the default value for TCL_PRESERVE_BINARY_COMPATABILITY. * generic/tcl.h (line 1208): Define the macro 'Tcl_InitHashTable' only when TCL_PRESERVE_BINARY_COMPATIBILITY is not set as it kills binary compatibility to 8.3 and earlier versions. This is the main part of the patch/change. * generic/tcl.decls (line 1469): * generic/tclHash.c (Tcl_InitHashTable): * generic/tclHash.c (Tcl_InitHashTableEx): * generic/tclObj.c (Tcl_InitObjHashTable): Changed 'Tcl_InitHashTableEx' to 'Tcl_InitCustomHashTable'. This change is more of an estethical nature, replacing the ubiquitous 'Ex' suffix with a more meaningful name. The introduced binary incompatibility is deemed acceptable as it is between alpha versions. Updated callers. * doc/Hash.3: * unix/mkLinks: Changed 'Tcl_InitHashTableEx' to 'Tcl_InitCustomHashTable'.
