apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: _FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE undefined when LFS enabled
Date Mon, 17 Sep 2007 17:20:14 GMT
Sorry.
I obviously sent the wrong patch ...
Fixed.


--
Lucian

On 9/17/07, Lucian Adrian Grijincu <lucian.grijincu@gmail.com> wrote:
> I'm exercising my puny autotools skills now. this may be erroneous and
> should be tested on platforms other than Ubuntu Linux x86.
>
> Basically it's down to this: compare ino_t with the size of uint,
> ulong and ulonglong.
> Which ever matches gets to be defined in apr.h
> If none match it will fall back to ino_t.
>
> Windows gets the same value as the one in include/apr_file_info.h,
> namely apr_uint64_t.
>
> I hope that NETWARE uses autotools too :)
>
> Do we need a APR_INO_T_FMT ?
>
> On 9/17/07, Joe Orton <jorton@redhat.com> wrote:
> > On Sun, Sep 16, 2007 at 05:51:39PM +0300, Lucian Adrian Grijincu wrote:
> > > Currently APR still uses ino_t in apr_file_info.h in trunk:
> > > http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_file_info.h?view=markup
> > > and compiling with _FILE_OFFSET_BITS=64 will change the ABI:
> > >    sizeof(apr_ino_t) == sizeof(ino_t) == 4 or 8 depending on the
> > > compile time flags.
> > >
> > > Removing the dependency on the ino_t and using Peter's patch will
> > > preserve ABI regardless of _FILE_OFFSET_BITS=64 being defined or not.
> > >
> > > Is this not considered a bug of the header files?
> >
> > Hmmm, good point, yes, it is. I'm not sure why this doesn't render the
> > off_t==long changes completely useless.  Do you have a patch?
> >
> > joe
> >
>
>

Mime
View raw message