Re: UTF-8 book is ready for merging
Pasha Zubkov wrote:
+ if (c 127) {
+ c = ((c ^ 192)
6) + (getc(p) ^ 128);
+ } else if (c 223) {
+ c = ((c ^ 224) 12)
+ ((getc(p) ^ 128) 6) + (getc(p) ^ 128);
+ } else if (c 239) {
+ c = ((c ^ 240) 18) +
((getc(p) ^ 128) 12) + ((getc(p) ^ 128) 6) + (getc(p) ^ 128);
+ }
+ } while (c != EOF
!iswprint(c)
As a general rule, you shouldn't implement UTF-8 support in such
hard-coded way. Please look at mbrtowcs() function and its friends. They
convert from the locale encoding (be it ru_RU.KOI8-R or ru_RU.UTF-8) to
wchar_t.
--
Alexander E. Patrakov
Don't mail to [EMAIL PROTECTED]: the server is off until 2006-01-11
Use my GMail or linuxfromscratch address instead
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: FAQ: Package management
Bruce Dubbs wrote: Mark Rosenstand wrote: On a side note: Another headline for Why isn't some package manager in the book? would be appreciated. http://www.linuxfromscratch.org/blfs/view/cvs/introduction/important.html#pkgmgt Yes. This is exactly what leads people to believe that they already know the answer to that question when they later see Why isn't some package manager in the book? in the FAQ. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 book is ready for merging
Alexander E. Patrakov пишет:
Pasha Zubkov wrote:
Alexander E. Patrakov пишет:
UTF-8 is _still_ not fully supported (e.g. 'tr :upper: :lower:' works
only on ASCII characters, 'watch' shows only ASCII characters,
'sfdisk' misaligns button labels in non-English UTF-8 locales), but
the same bugs exist in all distros (including those which claim that
they support only UTF-8). Because of that, such bugs should not be an
obstacle.x
Hello, this patch fix UTF-8 issue with `watch` at least in ru_RU.UTF-8
and be_BY.UTF-8.
Rejected, breaks ru_RU.KOI8-R.
Added test for UTF-8.
--- procps-3.2.6/watch.c2005-10-30 02:44:53.0 +0300
+++ procps-3.2.6.UTF-8/watch.c 2006-01-01 18:53:43.0 +0200
@@ -25,6 +25,8 @@
#include termios.h
#include locale.h
#include proc/procps.h
+#include wctype.h
+#include langinfo.h
#ifdef FORCE_8BIT
#undef isprint
@@ -144,8 +146,10 @@
float interval = 2;
char *command;
int command_length = 0; /* not including final \0 */
+ int utf8_mode;
setlocale(LC_ALL, );
+ utf8_mode = (strcmp(nl_langinfo(CODESET), UTF-8) == 0);
progname = argv[0];
while ((optc = getopt_long(argc, argv, +d::hn:vt, longopts, (int *)
0))
@@ -274,9 +278,19 @@
/* if there is a tab pending, just spit
spaces until the
next stop instead of reading
characters */
if (!tabpending)
- do
+ do {
c = getc(p);
- while (c != EOF !isprint(c)
+
+ if (utf8_mode) {
+ if (c 127) {
+ c = ((c
^ 192) 6) + (getc(p) ^ 128);
+ } else if (c
223) {
+ c = ((c
^ 224) 12) + ((getc(p) ^ 128) 6) + (getc(p) ^ 128);
+ } else if (c
239) {
+ c = ((c
^ 240) 18) + ((getc(p) ^ 128) 12) + ((getc(p) ^ 128) 6) + (getc(p) ^
128);
+ }
+ }
+ } while (c != EOF (utf8_mode
? !iswprint(c) : !isprint(c))
c != '\n'
c != '\t');
if (c == '\n')
@@ -304,7 +318,14 @@
}
if (attr)
standout();
+ if (utf8_mode) {
+ wchar_t wc = c;
+ cchar_t cc = {0, {}};
+ setcchar(cc, wc, 0, 0, NULL);
+ add_wch(cc);
+ } else {
addch(c);
+ }
if (attr)
standend();
}
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: UTF-8 book is ready for merging
Pasha Zubkov wrote: Alexander E. Patrakov пишет: Pasha Zubkov wrote: Hello, this patch fix UTF-8 issue with `watch` at least in ru_RU.UTF-8 and be_BY.UTF-8. Rejected, breaks ru_RU.KOI8-R. Added test for UTF-8. Why not just use getwc(), and use wchar_t's in all cases? You'd have to modify the output to convert back to multibyte characters (specifically, LC_CTYPE-encoding characters; they may not actually have more than one byte per character), but it looks like add_wch does that already. signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Essential Symlinks: Explainations
Tushar Teredesai wrote:
Additionally, the libgcc_s.so symlink is not needed. Only the
libgcc_s.so.1 is needed so that glibc can dlopen that library (used in
nptl).
Are you sure? The libgcc_s.so symlink became necessary when LFS adopted
the startfile_prefix_spec hackery in the toolchain readjustment to
overcome the link against wrong libc issue that I discovered way back
when. Recall some lively flam^H^H^H^H discussions on lfs-hackers from
Sept. 2004. Here is a relevant post:
http://linuxfromscratch.org/pipermail/lfs-hackers/2004-September/002154.html
Hmmm, looking at things currently, I see that the Stable book still does
the startfile_prefix_spec tweaking but the Unstable book does not! It was
lost when the GCC-4 branch was merged to the trunk. I haven't verified it
but ISTM that LFS Unstable has therefore regressed to linking Ch 6
Binutils and GCC against the (wrong) Glibc in /tools! Luckily, there is
enough redundancy within the build method to make this fairly harmless..
but it still doesn't escape that fact that it's just plain wrong. It
*WILL* bite in some scenarios eg: ICA will show up differences if you
happen to build different Glibc's in Ch 5 and Ch 6 (like I do in DIY -
non-optimized in temptools phase versus optimized in chroot phase).
You can verify the problem by running this test just AFTER the
readjustment of the toolchain and BEFORE the install of binutils and gcc
when INSIDE THE CHROOT:
echo 'main(){}' dummy.c
gcc dummy.c -Wl,--verbose 21 | grep succeeded
If you see references to /tools then you are linking against the wrong
libc! Someone urgently needs to check the Unstable book for this right now.
More detailed info here:
http://www.diy-linux.org/pipermail/diy-linux-dev/2004-August/000111.html
http://www.diy-linux.org/pipermail/diy-linux-dev/2004-September/000122.html
Apologies if I've overlooked something and wasted your time.. but
the test takes only seconds to run so someone really should perform the
test to determine the current status.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: UTF-8 book is ready for merging
Bryan Kadzban пишет: Why not just use getwc(), and use wchar_t's in all cases? You'd have to modify the output to convert back to multibyte characters (specifically, LC_CTYPE-encoding characters; they may not actually have more than one byte per character), but it looks like add_wch does that already. Just after a stream is associated with a pipe by the popen() function, the stream is byte-oriented. getwc() works only on wide-oriented streams -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: module-init-tools-3.2.2 : any ideas what I'm doing wrong?
On Sun, 1 Jan 2006, Bernard Leak wrote: Dear List, in what is (or was a few days ago!) the 'live' LFS Book (LFS-BOOK-SVN-20051223), I can't get the test-suite for 6.50, Module-Init-Utils to run *at all*. Ignoring the test result, everything seems to build, but I haven't dared install it on top of the existing version. In a fit of amazing helpfulness, the failure does its best to delete its own audit trail. The first test to be run, tests/test-depmod/01backcompat.sh , produces no output and returns an error, and the built objects are deleted before I can look at them! If 3.2.2 is like 3.2.1, you have to hack the file that runs the tests to stop it removing the output. That part isn't too difficult. Possibly also there might be some sort of 'VERBOSE' variable to define. Unfortunately, it's 5 or 6 weeks since I looked at m-i-t for CLFS, and I can't remember the detail other than it succeeded on the first tests. That problem was caused by a missing dependency of the testsuite, maybe mktemp. Unlikely to be your problem, but a couple of hours hacking the scripts will hopefully point you to the answer. Doubtless with patience and time I could modify the makefile and the associated scripts until I could get some sort of output, but I'd like to be told whether anyone else knows what I'm doing wrong... I'm fairly sure I must have crocked some part of my toolchain very heavily, but for some reason it hasn't showed up hitherto (and, yes, I do run testsuites and check the output!). Personally, I don't have a high regard for this testsuite (test both with and without zlib, instead of testing the desired build, and throw away the files each time; run a number of tests and report that all 1 tests succeeded, destroy the evidence on failure). Patience and time are almost always a requirement for the development book, particularly for people who deviate by rebuilding in-place ;) Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 book is ready for merging
Pasha Zubkov wrote: Bryan Kadzban пишет: Why not just use getwc(), and use wchar_t's in all cases? You'd have to modify the output to convert back to multibyte characters (specifically, LC_CTYPE-encoding characters; they may not actually have more than one byte per character), but it looks like add_wch does that already. Just after a stream is associated with a pipe by the popen() function, the stream is byte-oriented. Where is that quoted from? I was not aware that there was a difference between byte-oriented and wide-oriented streams. I thought getwc did the conversion between LC_CTYPE charset and wide-char itself, though I see the getwc manpage only says that it is reasonable to expect this in the absence of additional information passed to the fopen call. This Debian i18n page seems to imply that it should work (see 6.3), and it's what I was going from: http://www.debian.org/doc/manuals/intro-i18n/ch-locale.en.html But if there is a difference, then the iconv sample on that page (see 6.5) could be a better choice than hardcoding the UTF-8 conversion, and (therefore) only working in a UTF-8 charset environment. (Plus, you don't know what the user will set LC_CTYPE to; it might be utf8, it might be utf-8, it might be UTF8, and any of these will break the patch.) signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Various minor changes to the book
I've attached a patch for a few minor changes in the book. This includes a reduction in the Chapter 6 glibc explanatory text on locales (there is no reason for the same thing to be said both in Chapters 5 and 6) as well as a link to the new BLFS locale page, and a small change in Chapter 6 binutils (adding the meaning of the make parameter to make it consistent with the rest of the book), as well as a few other minor grammar issues. Index: trunk/BOOK/chapter05/introduction.xml === --- trunk/BOOK/chapter05/introduction.xml (revision 7239) +++ trunk/BOOK/chapter05/introduction.xml (working copy) @@ -49,7 +49,7 @@ importantparaAfter installing each package, delete its source and build directories, unless specifically instructed otherwise. Deleting the sources prevents mis-configuration when the same package is reinstalled later. -Only three of the packages need to retain the source and build directories in +Only two of the packages need to retain the source and build directories in order for their contents to be used by later commands. Pay special attention to these reminders./para/important Index: trunk/BOOK/chapter05/gettext.xml === --- trunk/BOOK/chapter05/gettext.xml(revision 7239) +++ trunk/BOOK/chapter05/gettext.xml(working copy) @@ -34,7 +34,7 @@ screenuserinputcd gettext-tools ./configure --prefix=/tools --disable-shared/userinput/screen -paraThe meaning of the configure options:/para +paraThe meaning of the configure option:/para variablelist varlistentry Index: trunk/BOOK/chapter05/grep.xml === --- trunk/BOOK/chapter05/grep.xml (revision 7239) +++ trunk/BOOK/chapter05/grep.xml (working copy) @@ -32,7 +32,7 @@ screenuserinput./configure --prefix=/tools \ --disable-perl-regexp/userinput/screen -paraThe meaning of the configure options:/para +paraThe meaning of the configure option:/para variablelist varlistentry Index: trunk/BOOK/chapter05/bash.xml === --- trunk/BOOK/chapter05/bash.xml (revision 7239) +++ trunk/BOOK/chapter05/bash.xml (working copy) @@ -32,15 +32,15 @@ screenuserinput./configure --prefix=/tools --without-bash-malloc/userinput/screen -paraThe meaning of the configure options:/para +paraThe meaning of the configure option:/para variablelist varlistentry termparameter--without-bash-malloc/parameter/term -listitemparaThis options turns off the use of Bash's memory +listitemparaThis option turns off the use of Bash's memory allocation (malloc) function which is known to cause segmentation faults. By turning this option off, Bash will use the malloc functions -from Glibc which are more stable./para/listitem +from Glibc, which are more stable./para/listitem /varlistentry /variablelist Index: trunk/BOOK/chapter05/gcc-pass1.xml === --- trunk/BOOK/chapter05/gcc-pass1.xml (revision 7239) +++ trunk/BOOK/chapter05/gcc-pass1.xml (working copy) @@ -72,7 +72,7 @@ screenuserinputmake bootstrap/userinput/screen -paraThe meaning of the make parameters:/para +paraThe meaning of the make parameter:/para variablelist varlistentry Index: trunk/BOOK/chapter06/binutils.xml === --- trunk/BOOK/chapter06/binutils.xml (revision 7239) +++ trunk/BOOK/chapter06/binutils.xml (working copy) @@ -59,16 +59,25 @@ screenuserinputmake tooldir=/usr/userinput/screen -paraNormally, the tooldir (the directory where the executables will ultimately -be located) is set to filename -class=directory$(exec_prefix)/$(target_alias)/filename. For example, i686 -machines would expand that to filename -class=directory/usr/i686-pc-linux-gnu/filename. Because this is a custom -system, this target-specific directory in filename -class=directory/usr/filename is not required. filename -class=directory$(exec_prefix)/$(target_alias)/filename would be used if the -system was used to cross-compile (for example, compiling a package on an Intel -machine that generates code that can be executed on PowerPC machines)./para + variablelist +titleThe meaning of the make parameter:/title + varlistentry + termparametertooldir=/usr/parameter/term + listitem +paraNormally, the tooldir (the directory where the executables will +ultimately be located) is set to filename +class=directory$(exec_prefix)/$(target_alias)/filename. For +example, i686 machines would expand that to filename +class=directory/usr/i686-pc-linux-gnu/filename. Because this is +a custom system, this target-specific directory in filename +class=directory/usr/filename is not required. filename +
Re: FAQ: Package management
Mark Rosenstand wrote: Bruce Dubbs wrote: Mark Rosenstand wrote: On a side note: Another headline for Why isn't some package manager in the book? would be appreciated. http://www.linuxfromscratch.org/blfs/view/cvs/introduction/important.html#pkgmgt Yes. This is exactly what leads people to believe that they already know the answer to that question when they later see Why isn't some package manager in the book? in the FAQ. Sorry. I couldn't parse the above comment. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
