On Sun, 31 May 2015 10:17:02 -0400 Mike Frysinger <vap...@gentoo.org> 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. Alexis.
