View Bug Activity | Format For Printing
http://cygwin.com/ml/cygwin-xfree/2009-10/msg00106.html libX11 doesn't understand about the C.UTF-8 locale, so XSupportsLocale() fails in that locale. Ordinarily this wouldn't be a problem, although applications will typically complain that "Warning: locale not supported by C library, locale unchanged" Unfortunately the server considers it a fatal error if XSupportsLocale() fails for internal clients. This is probably wrong.
Created an attachment (id=4340) Patch for appying to /usr/share/X11/locale to add C.UTF-8 to locales libX11 knows about
Created an attachment (id=4341) Corresponding source patch
Created an attachment (id=4342) XServer patch to make XSupportsLocale failure non-critical
(In reply to comment #3) > Created an attachment (id=4342) > XServer patch to make XSupportsLocale failure non-critical With cygwin 1.7.0-63 out, I think we need to push this quickly. Patch added to the queue for 1.7.1-2.
(In reply to comment #2) > Created an attachment (id=4341) > Corresponding source patch Thanks for the patch. What I don't understand is, if this C.UTF-8 locale is Debian's idea, why doesn't there libX11 have a similar patch[1]? [1] http://patch-tracker.debian.org/package/libx11/2:1.3-1
(In reply to comment #5) > (In reply to comment #2) > > Created an attachment (id=4341) > > Corresponding source patch > > Thanks for the patch. What I don't understand is, if this C.UTF-8 locale is > Debian's idea, why doesn't there libX11 have a similar patch[1]? > > [1] http://patch-tracker.debian.org/package/libx11/2:1.3-1 I don't know. Possibly because no-one actually runs their system in C.UTF-8. It looks like the idea is that C.UTF-8 is only intended for use in things like build environments which require a language-neutral but UTF-8 aware locale.
Server patch shipped in 1.7.1-2. I saw there was some further discussion about the xlib part of this patch; what was your conclusion?
(In reply to comment #7) > Server patch shipped in 1.7.1-2. I saw there was some further discussion about > the xlib part of this patch; what was your conclusion? I think the xlib changes are ok to publish. But there still some other odd behaviour being reported which I guess is due to no longer building with X_LOCALE.
Created an attachment (id=4376) Don't crash if conversion of window name to UTF-8 fails This fixes the crash, but windows just end up with blank titles. There's a deeper problem that Xlib doesn't seem to know how to convert strings to C.UTF-8 locale encoding (although this should be pretty trivial) :-)
(In reply to comment #9) > Created an attachment (id=4376) > Don't crash if conversion of window name to UTF-8 fails > > This fixes the crash, but windows just end up with blank titles. > > There's a deeper problem that Xlib doesn't seem to know how to convert strings > to C.UTF-8 locale encoding (although this should be pretty trivial) :-) Doh! I'd reverted the Xlib locale data patch. With that present, the window titles get converted correctly. So that seems pretty clear that both parts are actually needed :-) Perhaps the Xserver could be a bit smarter about fallbacks when trying to convert window titles and clipboard strings to the locale encoding, but I'm not sure how...
(In reply to comment #9) > Created an attachment (id=4376) > Don't crash if conversion of window name to UTF-8 fails Patch added to queue for 1.7.1-3. FYI, this didn't apply cleanly to 1.7.1 due to whitespace alignment differences, so the patch in SVN is slightly different to compensate.
Second patch for xserver shipped in 1.7.1-3. Patch for xlib shipped in 1.3.2-2. Closing.