On 31 May 2015 16:33, Alexis Ballier wrote: > On Sun, 31 May 2015 10:17:02 -0400 Mike Frysinger wrote: > > On 31 May 2015 15:52, Alexis Ballier wrote: > > > On Sun, 31 May 2015 13:50:49 +0200 Diego Elio Pettenò wrote: > > > > On 31 May 2015 at 12:59, Alexis Ballier wrote: > > > > > nice, but can't we add the lfs flags to our default toolchain > > > > > flags or even better patch glibc headers to always redefine > > > > > these functions to the 64bits variants? > > > > > > > > No, because that can easily break ABI of programs that actually > > > > want the non-LFS one (for instance anything that wraps around > > > > function calls, including but not limited to padsp, aoss, and > > > > similar wrappers.) > > > > > > This seems easily fixed with an opt-out for lfs flags that such > > > programs can use. They'll need to be touched to disable the QA > > > warning anyway. > > > > this is a discussion for upstream toolchain packages (largely glibc) > > and in fact i started such a heretical thread over a year ago. it > > was not well received due to the implicit/silent ABI change that new > > builds would receive. glibc likes to be conservative as it is the > > foundation of everything. > > > > so unless glibc changes, updating our copy of glibc would only > > somewhat help our users. conversely, getting the changes pushed to > > the respective upstream would help everyone. > > I'm not sure what's best for every one: > 1. Push hundreds of patches upstream to add lfs flags; > 2. Apply your patch to our glibc ebuilds, fix the corner cases, and go > back to glibc upstream with these data. > > Least to say is that I'm not a big fan of lfs flags as done in glibc and > I certainly prefer 2., but you'd know better.
well if we're going to do arbitrary lists ;) (1) your options aren't mutually exclusive (2) implementing both are desirable (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 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
signature.asc
Description: Digital signature
