[Python-bugs-list] [ python-Bugs-719880 ] _tkinter.c doesn't build on Redhat 9

SourceForge.net noreply@sourceforge.net
Sat, 12 Apr 2003 03:36:00 -0700


Bugs item #719880, was opened at 2003-04-11 21:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719880&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: _tkinter.c doesn't build on Redhat 9

Initial Comment:
Martin, _tkinter doesn't build on Redhat 9 because:
 _tkinter.c:92:2: #error "unsupported Tcl configuration"

TCL_UTF_MAX is defined to be 6, not 3.  I don't know
what else would be necessary to change to get this to
work.  Can you provide any ideas? 

I changed line 92 to:

    #if TCL_UTF_MAX != 3 && TCL_UTF_MAX != 6

and I was able to bring a window up with a push button.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-12 12:36

Message:
Logged In: YES 
user_id=21627

I just looked at their source RPM, and I can't believe what
I'm seeing :-(

There is tcltk-8.3.5-ucs4-for-py.patch, which reads

--- tcl8.3.5/generic/tcl.h~	2003-02-04 10:01:20.000000000 +0900
+++ tcl8.3.5/generic/tcl.h	2003-02-04 10:01:20.000000000 +0900
@@ -1604,13 +1604,13 @@
  * Unicode character in UTF-8.
  */
 
-#define TCL_UTF_MAX		3
+#define TCL_UTF_MAX		6
 
 /*
  * This represents a Unicode character.  
  */
 
-typedef unsigned short Tcl_UniChar;
+typedef wchar_t Tcl_UniChar;
 
 /*
  * Deprecated Tcl procedures:

I'd say they have tricked themselves: Py22 would fail to
work with Tcl in UCS-4 mode. Instead of fixing this in
tkinter (as I did for Python 2.3), they just patched tcl...
However, Tcl itself seems to be prepared for that mode of
operation; atleast their UTF-8 codec knows how to convert 6
bytes into a single int.

I would suggest that we mandate UCS-4 on Redhat 9 (through
README), and fix it for this case (i.e. allow UTF_MAX to be
6 only if unicode is wide, and narrow the UNICODE_WIDE test
to && UTF_MAX==3).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-11 22:38

Message:
Logged In: YES 
user_id=33168

Tcl/Tk version is 8.3.5. There were some warnings from
AsObj.  I'll look into this in more detail later.  I may ask
the redhat guys to take a look too.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-11 22:08

Message:
Logged In: YES 
user_id=21627

What Tcl version is that? I didn't know Tcl does UCS-4...

The comment says it all: Tcl_Unichar is expected to be two
bytes. If it isn't, and
a) Python is UCS-2: In AsObj, deal with surrogates in the
Python 
string, combining them into a single Tcl_Unichar. In
FromObj, split
non-BMP characters into two. This means that you need a copying
loop, as you cannot expect that the size of the Tcl and Python
strings will be the same.
b) Python is UCS-4. Consider also using
PyUnicode_FromUnicode in FromObj, and NewUnicodeObj in AsObj.

Alternatively, proclaim that "Tcl is UCS-4, Python is UCS-2"
is not supported, drop case a), and perform just the direct
operations in case b) (the current copying loops are still
needed for UCS-2 Tcl).

Perhaps Tcl isn't UCS-4, but uses surrogate pairs instead?
In that case, one would need to use yet other algorithms...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719880&group_id=5470