On 31 May 2015 11:58, Mike Gilbert wrote: > On Sat, May 30, 2015 at 2:54 PM, Mike Frysinger wrote: > > we've got a new QA check that warns whenever a package is built using a > > 32bit > > filesystem interface. in practice, this applies to arm/mips/ppc/sh/x86 > > systems > > (not including multilib -- for now). > > > > this topic has come up in Gentoo a few times over the years but we've never > > really amassed the will power to fix it. instead we fix it in one-offs > > based > > on user reports (like "can't download 4GiB file with ftp" #101038). this > > was > > worked well enough because most users have moved on to 64bit systems and the > > interaction with >2GiB files tends to correlate with a few packages. > > > > however, "recent" winds have started blowing where file systems are > > utilizing > > 64bit inodes to handle large file counts. this means apps that do even > > basic > > things like stat() will now fail. the number of applications that this > > affects > > is significantly higher, although still relegated to systems that happen to > > use > > a file system with 64bit inodes. > > Does this issue affect software that only reads/writes small files and > never calls stat? For example, pkg-config.
it is possible to use some file system operations and never run into problems.
the trouble is that it requires diligence and careful auditing, and you have to
make sure your interactions with other packages are also OK. considering how
bad/unaware the wider community is wrt LFS, ABI compatibility, and such
critical
but oft overlooked issues, i suspect most people also won't have the will
power/capabilities to keep up here.
conversely, flip the autoconf/cppflags magic, and most projects Just Work.
> It might still be nice to adjust such packages for consistency, but it
> might be harder to justify patches to upstream developers.
pkg-config already merged it and it's already been pulled back into Gentoo ;)
https://bugs.freedesktop.org/show_bug.cgi?id=90078
https://bugs.gentoo.org/550508
that said, i'm not entirely sure why there would be a lot of push back.
when i gathered data on this years ago (which i no longer have, so i'd have
to recreate), the increased foot print and runtime cost was not significant.
especially when you consider that we're talking about I/O operations which
inherently kill CPU performance due to stalls.
-mike
signature.asc
Description: Digital signature
