Re: building old coreutils versions on new glibc systems

[Jim Meyering]

On Thu, Aug 1, 2019 at 7:48 PM Assaf Gordon <address@hidden> wrote:
> While trying to find out the first version with the 'seq' bug
> (my previous email), I realized it has become quite hard to build
> old coreutils version on newer glibc system.
>
> In particular:
> 1. At some point 'gets' was removed from glibc, but old sources refer it.
> 2. Older gnulib used internal glibc symbols (libio.h) and the detection
> method changed (_IO_ftrylockfile vs _IO_EOF_SEEN).
> See:  https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=74d9d6a2
> 3. Old coreutils defined 'futimens','tee','eaccess' functions which conflict
> with later glibc functions of same name.
>
> In short, it's not trivial to download a tarball from
> https://ftp.gnu.org/gnu/coreutils/ and build it on modern systems
> (and it seems even more complicated to build from git).
>
> The attached patches enable building old tarballs on modern systems
> (tested on Debian 10 with GLIBC 2.28-10, gcc 8.3.0-6).
>
> The sequence should be:
>
>     wget https://ftp.gnu.org/gnu/coreutils/coreutils-5.97.tar.gz
>     tar -xf coreutils-5.97.tar.gz
>     cd coreutils-5.97
>     patch -p1 < ../coreutils-5.97-on-glibc-2.28.patch
>     ./configure
>     make
>
> Coreutils Versions             Patch file
> 5.0                            coreutils-5.0-on-glibc-2.28.patch
> 5.97 to 6.9                    coreutils-5.97-on-glibc-2.28.patch
> 6.10                           coreutils-6.10-on-glibc-2.28.patch
> 6.11                           coreutils-6.11-on-glibc-2.28.patch
> 6.12                           coreutils-6.12-on-glibc-2.28.patch
> 7.2  to 8.3                    coreutils-7.2-on-glibc-2.28.patch
> 8.4  to 8.12                   coreutils-8.4-on-glibc-2.28.patch
> 8.13 to 8.16                   coreutils-8.13-on-glibc-2.28.patch
> 8.17                           coreutils-8.17-on-glibc-2.28.patch
> 8.18 to 8.23                   coreutils-8.18-on-glibc-2.28.patch
> 8.24 to 8.29                   coreutils-8.24-on-glibc-2.28.patch
> 8.30 and newer                 [builds without patching]

Nice work. I've had to go through this process a few times over the
years, and having these handy patch files checked in and maintained
would make it easier to automate the process. I'm on the fence as to
whether it's worth checking them in, given how few of us end up
building all old versions like that. Selfishly, I want it. Now that I
write this, I conclude it's worth the small cost. No need to
distribute those files, of course, and anything that makes a
maintainer's job easier (for such a small cost) is worthwhile.