Eric Blake asks:
> > Should we just make GL_EARLY always invoke AC_SYS_LARGEFILE, so
> > that any application that uses gnulib automatically also supports large
> > files?
Yes. The 32-bit off_t is nowadays only historical baggage. There is normally
no good reason to _not_ use AC_SYS_LARGEFILE. I'd
Eric Blake-1 <[EMAIL PROTECTED]> writes:
> Should we just make GL_EARLY always invoke AC_SYS_LARGEFILE, so
> that any application that uses gnulib automatically also supports large
> files?
Won't that be overkill for applications (probably libraries)
that don't do any file I/O? 'configure' is bl
> > I was assuming that invoking AC_SYS_LARGEFILE is the programmer's
> > responsibility, because AC_SYS_LARGEFILE is a global switch.
>
> Yes, that was my assumption too. However, as you mentioned, any
> portable program that accesses files should use AC_SYS_LARGEFILE these
> days.
Should we j
"Bruno Haible" <[EMAIL PROTECTED]> writes:
> I was assuming that invoking AC_SYS_LARGEFILE is the programmer's
> responsibility, because AC_SYS_LARGEFILE is a global switch.
Yes, that was my assumption too. However, as you mentioned, any
portable program that accesses files should use AC_SYS_LAR
Eric Blake wrote:
> Is there any reason that using the clean-temp module does not AC_REQUIRE
> ([AC_SYS_LARGEFILE]) in the configure script? Without that, it is possible
> on some hosts that temporary files are artificially capped at 2GiB, even
> though enabling largefile support could make things
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 12/26/2006 2:34 PM:
> Is there any reason that using the clean-temp module does not AC_REQUIRE
> ([AC_SYS_LARGEFILE]) in the configure script? Without that, it is possible
> on
> some hosts that temporary files are artific
