Bug 1474 - xlib locale support broken without duplicate entries
Summary: xlib locale support broken without duplicate entries
Status: CLOSED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: * Other (show other bugs)
Version: unspecified
Hardware: x86 (IA32) All
: high normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: l10n
Depends on:
Blocks:
 
Reported: 2004-09-26 20:51 UTC by Xie Qian
Modified: 2011-10-15 16:23 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xie Qian 2004-09-26 20:51:37 UTC
Actually, I've report this bug on XFree86's bugzilla before, and it is fixed. 
While using Fedora Core 2 recently, I found the same problem still exist in 
xorg. I forward following from XFree86's bugzilla, and comment at the end.

==============================================
Each file of locale.dir, locale.alias and compose.dir has two parts which only 
differ in delimiters, the former uses white space to separate two components 
in a line, whereas the later uses a colon. With current implementation, only 
the later part is correctly parsed. The former part will be simply discarded.

This phenomenon is caused by 'R63Compat' flag is set to YES in 
xc/nls/Imakefile. I guess the flag is used to keep file format compatible with 
X11R6.3 xlib, but not sure. I don't see this compatibility make any sense. 

When I set 'R63Compat' to NO, make will complain error due 
to 'LinkFileSpecial' macro not being defined. I think this macro should be 
defined in xc/config/cf/Imake.rules, but it doesn't matter, because what 
should do is clear. Appropriate commands can be copied from other branches in 
the same file. I will attach a patch to xc/nls/Imakefile.

However, the redundant contents don't produce any visible bad effect, so I 
mark the severity as trivial. But it causes extra overheads in almost every X 
client's initialization process, and may confuse users who want to modify 
these files.

------- Additional Comment #1 From Xie Qian 2004-05-19 01:53 [reply] ------- 
Created an attachment (id=1217) [edit]
set R63Compat to NO

the patch mentioned in bug report.
------- Additional Comment #2 From dawes@xfree86.org 2004-05-19 22:13 [reply] -
------ 
(In reply to comment #0)

> This phenomenon is caused by 'R63Compat' flag is set to YES in 
> xc/nls/Imakefile. I guess the flag is used to keep file format compatible 
with 
> X11R6.3 xlib, but not sure. I don't see this compatibility make any sense. 

Yes, this is for compatibility with older versions of Xlib.  I don't know if
anyone still relies on this, but I'll change the default to NO and see if 
anyone
notices a problem.

> When I set 'R63Compat' to NO, make will complain error due 
> to 'LinkFileSpecial' macro not being defined. I think this macro should be 
> defined in xc/config/cf/Imake.rules, but it doesn't matter, because what 
> should do is clear. Appropriate commands can be copied from other branches 
in 
> the same file. I will attach a patch to xc/nls/Imakefile.

This has already been fixed in the current development version.

==========================================================
I don't have source code of xorg's xlibs, and I don't think my patch will work 
directly. I paste the content only for reference.

--- Imakefile.orig	2004-05-19 10:46:48.000000000 +0800
+++ Imakefile	2004-05-19 12:25:36.000000000 +0800
@@ -24,7 +24,7 @@
 all::
 
 #ifndef R63Compat
-#define R63Compat YES
+#define R63Compat NO
 #endif
 
 #ifndef Win32Architecture
@@ -56,7 +56,8 @@
 									@@\
 AllTarget(name.lt)							@@\
 	MakeDir($(BUILDLIBDIR)/locale)					@@\
-	LinkFileSpecial($(BUILDLIBDIR)/locale,name,$(BUILDLIBTOP)/../../
$(CURRENT_DIR)/name.lt) @@\
+	RemoveFile($(BUILDLIBDIR)/locale/name)				@@\
+	cd $(BUILDLIBDIR)/locale && $(LN) $(BUILDLIBTOP)/../
$(CURRENT_DIR)/name.lt name @@\
 									@@\
 InstallNamedNonExec(name.lt,name,$(XLOCALEDIR))			
	@@\
 									@@\
Comment 1 Xie Qian 2004-09-27 18:46:25 UTC
Any comments?
Comment 2 Ienup Sung 2005-01-10 13:12:47 UTC
Personally, I don't think people will have trouble as long as they are
forking their source code from the cvs. I also cc'd Alan and Toshi in this bug
report for thier comments.
Comment 3 Daniel Stone 2005-09-30 00:13:49 UTC
actually, it does cause problems.  if only colon-delimited entries are present,
then only UTF-8 locales work.  with en_AU generated in my glibc's locales,
LC_ALL=en_AU gedit complains that libX11 doesn't support the locale.  if I
re-add the R63Compat stuff, it works again.
Comment 4 Daniel Stone 2007-02-27 01:24:15 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 5 Jeremy Huddleston Sequoia 2011-10-02 13:09:35 UTC
old build system ... if this is still around in any form, please open a new bug.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.