You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2006/11/16 15:17:15 UTC

APR_HAS_LARGE_FILES and 64-bit builds

Should it be on or off?  IOW, should it mean that OS LFS support for
32-bit apps such as fstat64() is used, or should it mean that APR can
handle large files?

Here's how it is chosen today:

if test "${ac_cv_sizeof_off_t}${apr_cv_use_lfs64}" = "4yes"; then
    # Enable LFS
    aprlfs=1
    AC_CHECK_FUNCS([mmap64 sendfile64 sendfilev64 mkstemp64 readdir64_r])
else
    aprlfs=0
fi

Re: APR_HAS_LARGE_FILES and 64-bit builds

Posted by Joe Orton <jo...@redhat.com>.
On Thu, Nov 16, 2006 at 11:05:51AM -0500, Jeff Trawick wrote:
> On 11/16/06, Joe Orton <jo...@redhat.com> wrote:
> >Using sizeof(apr_off_t) should be sufficient for most cases where you
> >need to determine simply "can APR handle file sizes > 2Gb" at compile
> >time.
> 
> Something for the preprocessor would be nice.  sizeof() won't work and
> _FILE_OFFSET_BITS seems ugly.

APR never redefines _FILE_OFFSET_BITS, that's no use at all in general.  
Adding an APR_SIZEOF_OFF_T or something on the trunk seems not 
unreasonable.

joe

Re: APR_HAS_LARGE_FILES and 64-bit builds

Posted by Jeff Trawick <tr...@gmail.com>.
On 11/16/06, Joe Orton <jo...@redhat.com> wrote:
> On Thu, Nov 16, 2006 at 09:17:15AM -0500, Jeff Trawick wrote:
> > Should it be on or off?  IOW, should it mean that OS LFS support for
> > 32-bit apps such as fstat64() is used, or should it mean that APR can
> > handle large files?
>
> There was some discussion of this when the LFS stuff was going in,
> thread from msgid <20...@manyfish.co.uk>.
>
> I do think that the current definition is the probably the right one to
> be exposing as part of the API at preprocessor level, since it may be
> necessary to use at that level to be able to correctly interact with
> other libraries.  (mod_perl needs it like this, for example).
>
> Using sizeof(apr_off_t) should be sufficient for most cases where you
> need to determine simply "can APR handle file sizes > 2Gb" at compile
> time.

Something for the preprocessor would be nice.  sizeof() won't work and
_FILE_OFFSET_BITS seems ugly.

Index: testlfs.c
===================================================================
--- testlfs.c	(revision 475714)
+++ testlfs.c	(working copy)
@@ -31,7 +31,7 @@
 {
     ABTS_NOT_IMPL(tc, "Large Files tests require Sparse file support");
 }
-#elif APR_HAS_LARGE_FILES
+#elif _FILE_OFFSET_BITS > 32
 #define USE_LFS_TESTS

 /* Tests which create an 8Gb sparse file and then check it can be used

-/-

another ugly test:

APR_HAS_LARGE_FILES || APR_SIZEOF_VOIDP > 4

I don't see anything cleaner for 1.2 though*.

*a new symbol in trunk is possible

Re: APR_HAS_LARGE_FILES and 64-bit builds

Posted by Joe Orton <jo...@redhat.com>.
On Thu, Nov 16, 2006 at 09:17:15AM -0500, Jeff Trawick wrote:
> Should it be on or off?  IOW, should it mean that OS LFS support for
> 32-bit apps such as fstat64() is used, or should it mean that APR can
> handle large files?

There was some discussion of this when the LFS stuff was going in, 
thread from msgid <20...@manyfish.co.uk>.

I do think that the current definition is the probably the right one to 
be exposing as part of the API at preprocessor level, since it may be 
necessary to use at that level to be able to correctly interact with 
other libraries.  (mod_perl needs it like this, for example).

Using sizeof(apr_off_t) should be sufficient for most cases where you 
need to determine simply "can APR handle file sizes > 2Gb" at compile 
time.

Regards,

joe