On Sun, 31 May 2015 11:17:50 -0400 Mike Frysinger <vap...@gentoo.org> wrote:
> well if we're going to do arbitrary lists ;) > (1) your options aren't mutually exclusive > (2) implementing both are desirable good to know your longterm plan :) however, even if both can be done, i still don't see the point of going through patching if we end up changing the default anyway. > (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 ? > 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. -mike 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 :) Alexis.
