tag 642573 wontfix thanks Hi!
On Sat, 2011-09-24 at 14:25:44 -0700, Steve Langasek wrote: > On Sat, Sep 24, 2011 at 03:49:11PM -0500, Jonathan Nieder wrote: > > > I would like to suggest an addition to the default flags: the output of > > > getconf LFS_CFLAGS should be included in the CFLAGS/CXXFLAGS variables. > > > On > > > 32-bit archs, this gives the following: > > > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > > > > (on 64-bit archs, it returns an empty string.) > > > I think (for the reasons you mentioned, among others) that this would > > be a very scary change. > > Yes, it is a scary change, and would certainly need to be planned carefully. > I don't think that necessarily means that it's inappropriate or impossible, > but I think it would be something we want to coordinate on an archive-wide > basis... possibly waiting for a new debhelper compat level and the like > before turning it on. I don't think it's safe in general to enable LFS if the package has not been carefully reviewed first. There's other issues besides the off_t ABI changes which are problematic too. As I mentioned in [0] (sorry Steve for not CCing you!), the programs might be using ssize_t (or any other 32-bit type) instead of off_t (or other possible 64-bit types) which could cause file truncation, there's also the problem that the programs might assume they can slurp or mmap the whole file contents into memory which will not fly on a 32-bit system (besides being a problem too on 64-bit system when running out of memory). I also don't see how the debhelper compat level would relate to turning this on in dpkg-dev itself? [0] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642573#30> > > It also has a negative side-effect that Debian would no longer be doing > > its part to get > > > #define _LARGEFILE_SOURCE > > #define _FILE_OFFSET_BITS 64 > > > put directly in upstream's config.h when appropriate. > > In your estimation, when is it appropriate to do this? For the most part, I > don't think this is something that upstreams should be worrying about; the > exceptions, IMHO, are precisely the ones where we don't want this turned on > at the distro level (because it breaks the ABI). In all other cases, I > think upstreams should support building both ways, and distros should bear > the responsibility of getting LFS enabled where they want it. As mentioned above once the code has been reviewed (and tested), I think it's always appropriate to enable LFS, but this is something upstream should be involved with and be aware of so that they take it into account when writting their code. For example for any project using autoconf with AC_SYS_LARGEFILE, configure will get the --disable-largefile option that allows to control the feature. And IMO, that's where the downstream should be selecting what behaviour to choose, and not through the build flags. > > > I make this suggestion because we had lfs as a release goal nearly a > > > decade > > > ago already, and we've never really had very good coverage for this and > > > made > > > very little progress since then. > > > I wonder if it's possible to check the archive in some automated way > > for large file support problems. For example, on i386: > > > eu-readelf -s $binary | grep -e '\Wopen@' > > > Of course, this has some false hits when programs are deliberately > > using the old-fashioned APIs to read or write files that they know > > will be small (dash does that, for example). I'd check for all functions for which there's a 64 bit counterpart and for usage of the fts(3) family of functions which are not LFS ready. Then if those were periodically done and published somewhere so that people could see if there's obvious problems with their packages that'd help with the adoption, and also to get some approximate numbers on LFS uptake, still that would not mean applications are LFS safe. lintian might be an appropriate place for this, and if this got to be upgraded to warning at some point in the future packages could always override them in case explicit small file support was being used and actually desired. > > Hmm, running that command on binaries in /usr/bin/ tells a worse story > > than I expected. For example, dpkg itself doesn't seem to have > > large-file support. An optional build flag specification for this > > (like the current DEB_BUILD_MAINT_OPTIONS=hardening=pie) doesn't sound > > like a terrible idea, though as mentioned above it's better if people > > patch the upstream build systems instead of using it. :) > > A patch to make this an optional feature, without some plan for how we can > get this turned on by default (either in dpkg-dev, or in debhelper where it > would benefit the majority of packages) is not worth the effort. We've had > an opt-in way of doing this for years: > > DEB_CFLAGS_MAINT_APPEND := $(shell getconf LFS_CFLAGS) > > And the uptake has been poor. Giving maintainers another option they won't > use isn't an improvement. In any case I agree with what Jonathan has said in the other mails, and believe this is something upstream should be supporting directly. And given what I've written above I don't think adding this to dpkg-buildflags (in any form) is a good idea, even though I think widespread large file support is a really worthwhile goal. At the same time, I think the reason why the LFS goal might not have seen more adoption is just a matter of visibility and education, lintian (for example) could cover the first, and a wiki page explaining how to write LFS safe code could cover the second. As such I think this bug report should be tagged wontfix (or closed), doing the first for now. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
