[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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?

Reply to: