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
E these
> days.
Should we just make GL_EARLY always invoke AC_SYS_LARGEFILE, so
that any application that uses gnulib automatically also supports large
files?
--
Eric Blake
--
View this message in context:
http://www.nabble.com/clean-temp-and-large-files-tf2883778.html#a8167594
Sent from th
"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
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 behave otherwise. As a
