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

[Mike Frysinger]

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.

> > 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.  using portable build systems (like autotools) lets you easily 
enable features like this and the build system knows the various platform
details.  if you decided to roll your own build system or use one that
isn't that portable, well that's kind of your fault isn't it ?  if you've
opted to only support a subset of systems, then that means adding these
CPPFLAGS yourself.
-mike