|
From: | Matthew Burgess |
Subject: | Re: Building coreutils in Linux From Scratch |
Date: | Thu, 24 Aug 2006 19:15:25 +0100 |
User-agent: | Thunderbird 1.5.0.5 (X11/20060728) |
Paul Eggert wrote:
Matthew Burgess <address@hidden> writes:http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-uname-1.patch What would be the preferred method of seeing the -i and -p flags of uname produce correct output on x86-linux machines? I'm assuming it needs either kernel or glibc cooperation?Yes, that's the idea. Partly because we don't want to have to maintain the "major hack", but more because this info really belongs in the kernel or C library, not in application code. We don't much care which syscall does the job (as you can see from the existing uname.c), so long as some syscall does it.
OK, I guessed as much. Unfortunately I'm not a kernel or libc hacker, nor do I play one on TV :-) I've taken a look at the patch Mike Frysinger pointed me to, and it looks at least a little more sane, so I'll propose to the LFS community that we use that one instead, for the time being anyway.
http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-suppress_uptime_kill_su-1.patch prevents `uptime', `kill' and `su' from being installed as we use binaries from the procps and shadow packages instead. As this is specific to LFS, I won't propose that GNU Coreutils apply it upstreamOK. For 'su' I understand -- we've been toying with the idea of removing it from coreutils -- but why is this the case for uptime and kill? What features are in procps uptime and kill that are not in coreutils?
Both versions of kill and uptime offer the same features. There is a minor incompatibility in that `kill -t` in coreutils maps to `kill -L` in procps. The main reason we suppress their installation is so that if folks decide to upgrade either procps or coreutils, they're guaranteed to run the binaries from the package we expect them to be provided by. This obviously makes resolving problem reports easier as we won't go around chasing our tails looking for a bug in procps' `kill' when it's actually in coreutils implementation (or vice versa, of course).
We could just as easily patch procps to prevent it from installing its versions of those two programs, but as we're preventing installation of `su' as it is, it made sense to suppress coreutils kill and uptime in the same patch.
http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-i18n-1.patch fixes a number of issues related to using the Coreutils binaries in multibyte locales. Although the patch header states that this patch has been rejected by yourselves before, it also states that the fixes it provides are planned for 6.0. As the patch largely applied as-is to 6.1, and I couldn't see anything relevant in NEWS, I'm assuming those fixes haven't made it in yet?That's right. The intent is to support it eventually, but those patches head in the wrong direction. They're incomplete, and don't fix many commonly-used programs like 'ls'. And they make the code significantly harder to maintain.
Is there anything I can do to help out with regard to this? Would you accept patches that add i18n related testcases, which XFAIL for the time being?
We also perform `sed -i 's/_LEN 6/_LEN 20/' src/who.c` with the following explanation: "It has been found that translated messages sometimes overflow a buffer in the who -Hu command." If I've understood the source correctly, the buffer overflow can occur in several locales because of the translation of " old ".That's an old bug, and was fixed a while back, by this: sprintf (idlestr, "%.*s", IDLESTR_LEN, idle_string (last_change, boottime)); So no matter how long " old " is translated to, the sprintf truncates it after IDLESTR_LEN bytes.
Fantastic, thanks for that (and also to Mike for pointing the same thing out). I'll remove that sed from the book.
Thanks, Matt. PS: Apologies to Paul, who received a private reply earlier today!
[Prev in Thread] | Current Thread | [Next in Thread] |