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 Sun, 16 Sep 2007 14:51:39 GMT
Currently APR still uses ino_t in apr_file_info.h in trunk:
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 <peter@p12n.org> 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).
> Version: GnuPG v1.4.6 (GNU/Linux)
> /ZhhYgQVmW71UffTned5xWc=
> =z8Gf

View raw message