On Monday 07 March 2011, Russ Allbery wrote: > Stefan Fritsch <s...@sfritsch.de> writes: > > I fear this affects more packages: I have looked at all packages > > that depend on libapr1 or have libapache2 in their name. From > > those, I have grepped for FILE_OFFSET_BITS in their newest > > kfreebsd build log. If I didn't do something wrong, these > > packages need to be binNMUed: > > > > fsvs > > libapache2-authenntlm-perl > > libapache2-mod-perl2 > > php5 > > php-svn > > rapidsvn > > speedy-cgi-perl > > subversion > > webauth > > I don't entirely understand this issue, but webauth uses apxs2 -q > CFLAGS, which should include equivalent information to apr-config > --cppflags (or there's something else weird going on).
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. > Certainly no objections to a binNMU, though. It can't hurt. 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 fsvs libapache2-mod-perl2 php5 php-svn rapidsvn subversion Does this make sense together with my explanations above? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
