I had problems updating Emacs to use gnulib commit
fde88b711c9b1df5b142444ac7b0bc2aa8892d3a along with emacs commit
fd859fbea2e9d13e76db1c5295d9ddd1c5955d83 (these are the same commits as
I mentioned earlier today). I reproduced it like this:
cd emacs
admin/merge-gnulib
The resulting lib/gnulib.mk.in had a line:
-e 's|@''HAVE_OFF64_T''@|$(HAVE_OFF64_T)|g' \
but there was no "HAVE_OFF64_T = @HAVE_OFF64_T@" line, and this caused
the "#if !@HAVE_OFF64_T@" line in lib/sys_types.in.h to become "#if !"
in lib/sys/types.h which is a syntax error in C.
I plan to work around the problem in Emacs by changing
admin/merge-gnulib to remove m4/off64_t.m4, and putting the following
into configure.ac instead:
# Emacs does not need to check for off64_t.
AC_DEFUN([gl_TYPE_OFF64_T],
[HAVE_OFF64_T=1
AC_SUBST([HAVE_OFF64_T])])
This is of course fragile.
It strikes me that apps like Emacs and coreutils don't need (and
shouldn't use) off64_t which was merely intended as a transitional type
in the 1990s, so there should be some way for them to disable the
off64_t business without the abovementioned sort of fragile hackery. A
documented way to disable off64_t discovery should simplify
configuration and make it less likely to run into glitches such as the
one I ran into with Emacs.
