Bug#616590: nmu: php5_5.3.5-1
Stefan Fritsch <email@example.com> writes:
> Maybe my initial report was misleading. Packages which *only* use apxs
> or apr-config to determine CFLAGS/CPPFLAGS should be fine. If they have
> another means to add additional CFLAGS/CPPFLAGS (in particular -
> D_FILE_OFFSET_BITS=64), they may be affected by the problem.
> To give some background, apr has some "typedef ino_t apr_ino_t" in a
> header file. The problem is that ino_t changes size depending on
> _FILE_OFFSET_BITS. libapr1 itself is compiled with 32bit ino_t (without
> _FILE_OFFSET_BITS=64). The fixed libapr1 has "typedef unsigned int
> apr_ino_t" or "typedef unsigned long apr_ino_t" in its headers instead,
> which does not depend on the compiler flags.
Ah! I understand now. Thank you.
> Webauth is a false positive. It seems to use -D_FILE_OFFSET_BITS=64 only
> for compiling some perl XS files and not for most other object files.
> If I restrict my grep to only include packages which have
> _FILE_OFFSET_BITS and apr (like in -I/usr/include/apr-1.0) occuring on
> the same line in the build log, the list is only
> Does this make sense together with my explanations above?
Yes, but note that _FILE_OFFSET_BITS could be set in config.h, in which
case the grep won't find things, so the set of affected packages could be
larger than you're detecting. Packages that use Autoconf's
AC_SYS_LARGEFILE macro will generally put those settings into config.h
instead of on the command line.
WebAuth is indeed a false positive because WebAuth never attempts to
enable large file support, but there may be other packages that do via
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>