Sorry. I obviously sent the wrong patch ... Fixed.
-- Lucian On 9/17/07, Lucian Adrian Grijincu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > >
apr_ino_t_patch_autotools_checked
Description: Binary data
