Re: [gentoo-dev] LFS QA warnings coming soon to a build near you

[Alexis Ballier]

On Tue, 2 Jun 2015 10:13:54 -0400
Mike Frysinger <vapier@g.o> 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.