gnulib-tool problem with off64_t and Emacs

[Paul Eggert]

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.