http://mail.gnu.org/archive/html/autoconf/2003-11/msg00039.html
A little discussion sprang up orginally started how to enable largefile support for C programs within a win32 environment. That's not quite the same as in posixish systems as there is no off_t available and no magic define in the compiler environment. In the course of discussion, we did wonder how much the win32 C library (usually in MSVCRT) does actually provide us with largefile support - finally, Bob Friesenhahn had the final word on it, answering to my question:
|
On Mon, 10 Nov 2003, Guido Draheim wrote: > > With win32 systems that might be slightly different however since > here the libc is not system-specific but compiler-specific. Each > compiler vendor and compiler version may link its programs with > a different libc implementation and it is uncertain whether that > libc implementation takes advantage of kernel largefile calls. > Actually, I just do not know but I expect that the most simple > path has been used and the win32 stdio api is fully limited to > 32bit on 32bit cpus, but that nay FUD and we better ask a guru. Regardless of the wonders of Windows-NT, XP, etc., the WIN32 API is still hobbled by an expectation that most pre-compiled programs will be able to run under Windows '95. Microsoft at least exposes the underscore "raw" API calls necessary to support 64-bits. It seems that Borland does not. MinGW uses the libc DLL that comes on every Windows system so it does provide access to the underscore API calls. It seems that at least for the Microsoft compiler, Cygwin, and MinGW, Autoconf could arrange to provide some compatibility defines to allow POSIX-style read/write code to compile and run with large file support. |
At the moment however, there is no automatism in autoconf to allow largefile be used for an application. You have to add your own checks and header defines that forward the calls to raw file access on to their *i64 largefile variants exported by the kernel. And do not expect the C library's stdio part to use largefile internally. Assume there is no fseeko() function and that fileno() returns a 2gig-limited handle. A vFAT filesystem does not support larger files anyway, only NTFS does.