On Sat, Sep 24, 2011 at 03:49:11PM -0500, Jonathan Nieder wrote: > > Three cheers for the new dpkg-buildflags interface!
> > 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. > 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. > > 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 would expect this to have a lot of false-positives in general; I see that there is an open64() call, but I'm not sure why given that off_t is not part of the open() API and a fd opened by one should be usable by the other. Probably better to check for those calls that explicitly use off_t. > 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
