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? -- Lucian Adrian Grijincu On 2/14/07, Peter Samuelson <[EMAIL PROTECTED]> wrote: > > [sorry for late reply, I'm catching up a bit on old list mail] > > [Lucian Adrian Grijincu] > > apr_dir_read puts the returned data in and apr_finfo_t structure, which > > has an apr_ino_t field. This field is 4 or 8 bytes in size dependent on > > _FILE_OFFSET_BITS=64 being either undefined or defined. > > Indeed - but forcing every apr-using application to also use LFS is not > optimal either. > > We ran into this issue in Debian, and kludged it by patching > apr_file_info.h not to use ino_t at all, but instead 'unsigned int' or > 'unsigned long' depending on platform. I also added a build-time test > to ensure we're using the same field size on each platform that we did > before the patch, so as not to change our ABI (so apps did not need to > be recompiled). > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFF0imLXk7sIRPQRh0RApMDAJoCnvyRlxsR2SRaHOjwOOIC05BCmwCeKd9v > /ZhhYgQVmW71UffTned5xWc= > =z8Gf > -----END PGP SIGNATURE----- > > >
