On Tue, 2 Jun 2015 10:13:54 -0400 Mike Frysinger <vap...@gentoo.org> wrote:
> On 01 Jun 2015 10:15, Alexis Ballier wrote: > > On Sun, 31 May 2015 11:17:50 -0400 Mike Frysinger wrote: > > > (3) considering the glibc effort has been stalled for over a year, > > > (1) is something we can help accomplish and make reasonable > > > progress on (4) glibc isn't the only one that implements LFS in a > > > transparent backwards compatible manner > > > > maybe the fact that some file operations are broken with glibc's > > default settings on a somewhat popular fs would be a good argument > > to un-stall it ? > > it isn't that black & white. while for many packages the change > would be harmless, glibc is more conservative than that. it can be > shown that a not uncommon coding style is to use long's everywhere > when dealing with the fs. when sizeof(off_t)==sizeof(long), this > works out. when off_t is suddenly twice as large, then you can get > truncation at best (which is kind of the status quo) and random > corruption at worse (like an API that takes pointers to off_t's but > the caller passed in a long). if you want to join the list upstream > and contribute to the discussion, you're more than welcome to. the > maintainers aren't clueless -- they fully understand the trade-offs > we're discussing here and know that 32bit fs accesses lead to > failures (including stat). > > since sitting on our hands and hoping for the best continues to > accomplish nothing, getting the various upstream packages to opt-in > to LFS themselves can make real progress now. agreed, thanks for the explanation i take it as the main goal of these qa warnings is to fix the above mentioned half broken packages and that pushing lfs flags everywhere is a slow but safe way to achieve it :) it'd be interesting to have data about how many packages can break; my belief is that more than half the c/c++ programs use one way or another fs ops but maybe less than one in a thousand will break; i can understand this is still too much for a libc (even though other 'breaking fixes' weren't so controversial in the past), and we'll see after gathering the data your qa warnings will provide > > > which leads me to the next part ... my first suggestion in the > > > tracker is for autotool based projects to use AC_SYS_LARGEFILE > > > because: (a) it supports a variety of systems > > > (b) as new systems come up or bugs are found or whatever, the > > > autoconf macro will improve and people eventually get those fixes > > > for free (c) it does it all transparently for you -- add the > > > macro and you're done (d) it fixes the package for all users, new > > > & old > > > > > > the reason i listed only the raw CPPFLAGS and autoconf macros are > > > because those are the two i'm familiar with. i don't know how > > > other build systems (e.g. cmake) support this (assuming they do > > > at all). if people have other recipes on hand, then it would be > > > great to collect more there. > > > > yes, but that is not what i am discussing: unless i missed > > something, they'll all end up one way or another adding the > > relevant defines; whether it is done with an m4 macro, > > append-lfs-flags, a cmake function or what else is an > > implementation detail of little interest to me trying to understand > > why we don't simply change the default :) > > as i already said, changing the default in *glibc* doesn't help > non-glibc systems. even with ten different libc's, the order of magnitude is still smaller for changing the default :) Alexis.
