Hi Victor, Normally the large file creation should not fail on the 32 bit builds. And -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 will create other side effects such as off_t getting to long long rather than long and similar with size_t (I guess).
The solution is to access/create the file along with the following flag O_LARGEFILE option. Please note that this option is not needed for FreeBSD as this OS uses 64 bit offsets by default. For windows, if you have to create a file larger than 4 GB, then you have to have NTFS file system and not FAT32 (FYKI) HTH, Regards, Jayavasanthan J. On 8/21/07, Victor Secarin <[EMAIL PROTECTED]> wrote: > > Having built sqlite 3.4.2 for Enterprise 3, 4, Fedora 5 and Solaris 8, > both 32 and 64 bits, I then ran the fulltest on each. As it takes a long > time and produces a large output, one looks first at the end, and if it > says "0 errors" one thinks everything is as expected. > > By chance, I later discovered the following: > > ================================================ > > ./testfixture ../sqlite-3.4.2/test/bigfile.test > bigfile-1.1... Ok > **** Unable to create a file larger than 4096 MB. ***** > Memory leaked: 0 bytes in 0 allocations > > soft-heap-limit changed by this script from 0 to > Thread-specific data deallocated properly > 0 errors out of 2 tests > Failures on these tests: > ================================================== > > This happens on all my 32 bit builds. Not on the 64 bit ones. > In order to get large file functionality one has to configure with > CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" > > The problem is that "Unable to create a file larger than 4096 MB" is not > considered a failure, so that people who only see the "0 errors out of > 409660 tests" at the end of the log file will not know they have the > problem. > It is really difficult to read the whole log file. > I suggest to > (a) make this a counted error, or else > (b) add an extra test specially for this problem, or else > (c) categorize the messages, prefixing them with a small number of > standard words, like "ERROR:" and "WARNING:" and "INFO:", which would > enable one to use grep or search in an editor. Then the problem above > could be a WARNING rather than a counted ERROR. > > > yours truly, > Victor Secarin >
