Ticket History #8474: gnu libc OFD lock bug affects krb5

In 1.14, we changed krb5_lock_file() to use OFD locks when possible
(ticket #8023). Unfortunately, a bug in gnu libc can cause this code to
fail on 32-bit Linux:

https://sourceware.org/bugzilla/show_bug.cgi?id=20251

This bug does not appear to be fixed. We can work around it by using
struct flock64 and fcntl64() in the appropriate circumstances.

This has come up on the Kerberos list (one thread with messages in two
different months) and in a Debian bug:

http://mailman.mit.edu/pipermail/kerberos/2015-December/021101.html
http://mailman.mit.edu/pipermail/kerberos/2016-August/021351.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834035

It does not appear that there is a fcntl64() function in glibc, so I
think the workaround would have to use syscall().

There is a struct flock64 in the header files (for use with F_SETLK64 and
friends, I think). Passing this to unmodified fcntl() currently works on
32-bit Linux, but that seems like a bad workaround because it depends on
the buggy behavior. If the glibc bug is fixed in the future, glibc would
be committing an aliasing violation reading values from a struct flock64
as a struct flock. In practice it would probably just read the same zero
offsets as we want to set in the first place, though.

As an alternative, we could disable OFD locking on 32-bit Linux, and
later re-enable it with a __GLIBC_PREREQ() check when there a fixed
version. But there's a chance that the upstream bug will never be fixed
because of compatibility concerns, and it would be a shame to never get
OFD locking on 32-bit Linux.

This bug was fixed in glibc by commit
06ab719d30b01da401150068054d3b8ea93dd12f on 2018-04-04. Based on the
date and git logs, release 2.28 is the first release with the fix.