Re: Building coreutils in Linux From Scratch

[Paul Eggert]

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.


> 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

OK.  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?


> 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.


> 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.