I have attached the working patch I have ended up using, which has added
only a definition for ENOSYS.

Thanks again. It's nice to be offering software for these machines with
working, current libc. :)

Satadru

On Thu, Feb 17, 2022 at 5:48 PM Rich Felker <dalias@libc.org> wrote:

> On Thu, Feb 17, 2022 at 04:43:51PM -0500, Satadru Pramanik wrote:
> > > issues in userspace to maintain some functionality for any users who
> may
> > > > still be using the device.
> > > >
> > > > The simplest workaround possible would be ideal.
> > >
> > > If you're shipping binaries specifically for these devices, the
> > > simplest fix is just to emulate the failure that should happen in the
> > > kernel in userspace, using the attached patch. DO NOT deploy this
> > > patch in binaries meant to be used on modern systems, since they will
> > > break when Y2038 rolls around. (Your old Chromebooks will break then
> > > too.)
> > >
> > I'll let the next generation of preservationists worry about the Y2038
> > issues. Thanks for the patch. I'll build that now with the
> >
> https://git.musl-libc.org/cgit/musl/patch/?id=c2feda4e2ea61f4da73f2f38b2be5e327a7d1a91
> > reversal patch for the i686 machines, and see if that fixes the issue. If
>
> That reversal should no longer be needed with the other patch, which
> is a much bigger hammer. Reversing that just got rid of using the new
> socket-related syscalls; the new hack patch gets rid of using all new
> syscalls.
>
> > so, we can consider the matter closed, unless you want to suggest a
> > modification of the syscall patch to handle older working kernels which
> > might avoid the need for the patch when used with older systems.
>
> The patch is fine for older broken or older working systems. It just
> suppresses the ability to use any syscall added after Linux 3.8, so
> it's a bad idea to use on *newer* systems.
>
> > > It is interesting though
> > > > that the sample program works fine when built against near-stock
> glibc
> > > > 2.23, no?
> > >
> > > No. If your kernel has a bug that makes something behave wildly wrong,
> > > whether you do or don't see that as visible breakage with a particular
> > > piece of software is not particularly interesting.
> > >
> > > I'm pretty sure, however, that you just haven't tested enough to see
> > > any failures. glibc 2.23 is from 2016, so any functionality in it
> > > using syscalls added after 2011 (3.8 kernel) is going to blow up
> > > badly, thinking the syscall succeeded and returned some positive value
> > > when actually the kernel lacks it.
> > >
> > > In the particular case of clock_gettime, it's just that your glibc
> > > 2.23 has a hard Y2038 EOL and does not use/support the missing time64
> > > syscalls.
> > >
> > >
> > Duly noted.
> >
> > Thanks so much for being patient while I got you enough information to
> fix
> > this!
> >
> > On behalf of the entire Chromebrew community, thank you!
>
> And thanks for reporting, running tests, and following through on
> this. It will be useful to know this is an issue others might hit, and
> to be able to check other old systems that might have backported the
> patch with the bug.
>