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
Description: Binary data
