| 1 |
On Sun, 31 May 2015 10:17:02 -0400 |
| 2 |
Mike Frysinger <vapier@g.o> wrote: |
| 3 |
|
| 4 |
> On 31 May 2015 15:52, Alexis Ballier wrote: |
| 5 |
> > On Sun, 31 May 2015 13:50:49 +0200 Diego Elio Pettenò wrote: |
| 6 |
> > > On 31 May 2015 at 12:59, Alexis Ballier wrote: |
| 7 |
> > > > nice, but can't we add the lfs flags to our default toolchain |
| 8 |
> > > > flags or even better patch glibc headers to always redefine |
| 9 |
> > > > these functions to the 64bits variants? |
| 10 |
> > > |
| 11 |
> > > No, because that can easily break ABI of programs that actually |
| 12 |
> > > want the non-LFS one (for instance anything that wraps around |
| 13 |
> > > function calls, including but not limited to padsp, aoss, and |
| 14 |
> > > similar wrappers.) |
| 15 |
> > |
| 16 |
> > This seems easily fixed with an opt-out for lfs flags that such |
| 17 |
> > programs can use. They'll need to be touched to disable the QA |
| 18 |
> > warning anyway. |
| 19 |
> |
| 20 |
> this is a discussion for upstream toolchain packages (largely glibc) |
| 21 |
> and in fact i started such a heretical thread over a year ago. it |
| 22 |
> was not well received due to the implicit/silent ABI change that new |
| 23 |
> builds would receive. glibc likes to be conservative as it is the |
| 24 |
> foundation of everything. |
| 25 |
> |
| 26 |
> so unless glibc changes, updating our copy of glibc would only |
| 27 |
> somewhat help our users. conversely, getting the changes pushed to |
| 28 |
> the respective upstream would help everyone. |
| 29 |
|
| 30 |
|
| 31 |
I'm not sure what's best for every one: |
| 32 |
1. Push hundreds of patches upstream to add lfs flags; |
| 33 |
2. Apply your patch to our glibc ebuilds, fix the corner cases, and go |
| 34 |
back to glibc upstream with these data. |
| 35 |
|
| 36 |
Least to say is that I'm not a big fan of lfs flags as done in glibc and |
| 37 |
I certainly prefer 2., but you'd know better. |
| 38 |
|
| 39 |
|
| 40 |
Alexis. |
Archives