Building coreutils in Linux From Scratch

[Matthew Burgess]

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.