Hi folks.
Firstly, the good news :-) The new experimental 6.1 release builds and
completes the testsuite fine on a recent Linux system (linux-2.6.17.8,
gcc-4.1.1, glibc-2.3.6).
Now for the nitty gritty!
There are instructions for building Coreutils at
http://www.linuxfromscratch.org/lfs/view/development/chapter06/coreutils.html
. You'll notice that the instructions are a little way off the simple
'configure && make && make check && make install' that I'd prefer to
have in the Linux From Scratch book.
We currently apply 3 patches to the vanilla GNU releases:
http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-uname-1.patch
changes the output of `uname -i' and `uname -p' from 'unknown' to the
correct platform and processor respectively on x86 machines running
Linux. I don't expect you to apply the patch as-is (I'm pretty certain
the comment of "major hack" would be enough to see to that!). 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?
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 upstream
:-) In an ideal world, it might be nice to have '--disable-[progname]'
options to configure, but with the number of utilities that Coreutils
provides, I doubt that'd be manageable/maintainable. If you think
otherwise, I can try to produce a patch that implements that.
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?
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 ". For example,
in po/rw.po it's translated as "ki/ bishaje" which obviously won't fit
in the 6 characters allocated to it in IDLESTR_LEN. Admittedly,
increasing it to 20 is a little silly, as it currently only needs 11 (+
1 for the terminating null, which is added at src/who.c:325).
I've not posted a patch to fix this up, as I'm not sure what the correct
approach is. There's the trivial patch that increases '6' to '11',
which I think is big enough to hold the longest of the existing
translated strings. Obviously, if someone updates a translation with a
longer string, IDLESTR_LEN will need to be increased again. Bearing
that in mind, would changing idlestr to be a 'char *' be a better fix?
Thanks,
Matt.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
