Bug#616590: nmu: php5_5.3.5-1
On Monday 07 March 2011, Russ Allbery wrote:
> Stefan Fritsch <sf@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?
Reply to: