On 01/06/2005, at 4:43 PM, Bryn Davies wrote:
> I think _that_ problem is addressed by making APR open all it's files
> with O_LARGEFILE. Of course, just tacking APR_LARGEFILE everywhere
> won't help unless O_LARGEFILE was defined in APR at compile time - it
> uses this as the gate condition for including the flag, not
> _LARGEFILE_SOURCE as you might expect.
First, I was wrong to natter on about apr_seek_where_t being
incorrectly sized. apr_seek_where_t is actually the 'whence'
parameter to lseek, not the offset itself. I must have looked at
this code six or seven times before sending those last letters, and
made the same mental mistake each time. Sometimes I wonder how I
dress myself every morning. The problem with seeking was actually
down to the sizing of apr_off_t ( which in retrospect seems like,
"duh" ). Fortunately, I have found the configuration parameter that
seems to control this - APR_HAS_LARGE_FILES inside apr.h.in. The bad
news is, this seems to in most cases end up being off_t afterall,
which is subject to shapeshifting on linux and Solaris.
You can see in apr.hw ( the windows apr.h ) that apr_off_t actually
gets redefined to __int64 if APR_HAS_LARGE_FILES is on, but
APR_HAS_LARGE_FILES seem to have no other effect. Looks like it's
back to the configure.in drawing board for me.
I have half of a patch written which puts the Largefile Autoconf
macro's into the apr configure.in, which can then be used with --
enable-largefile, but on Linux these macros for some reason don't
define -D_FILE_OFFSET_BITS=64 in the cflags, which is neccessary to
get a correct off_t size. I was experimenting with this on my
friends linux machine when it suddenly ran out of process handles and
died horribly. I may have to see if I can pick up development using
qemu and knoppix or something.
I wrote a little test program to check if things were working
properly, I don't know APR so it's probably stylistically ghastly.
I'm just going to chuck it on here if people want to test if their
APR's handle large files gracefully.
"There were too many of us. We had access to too many, uh, too much
Too much equipment... and little by little we went insane."
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jun 2 01:39:25 2005
- application/octet-stream attachment: aprtest.c