| 1 |
On 31 May 2015 16:33, Alexis Ballier wrote: |
| 2 |
> On Sun, 31 May 2015 10:17:02 -0400 Mike Frysinger wrote: |
| 3 |
> > On 31 May 2015 15:52, Alexis Ballier wrote: |
| 4 |
> > > On Sun, 31 May 2015 13:50:49 +0200 Diego Elio Pettenò wrote: |
| 5 |
> > > > On 31 May 2015 at 12:59, Alexis Ballier wrote: |
| 6 |
> > > > > nice, but can't we add the lfs flags to our default toolchain |
| 7 |
> > > > > flags or even better patch glibc headers to always redefine |
| 8 |
> > > > > these functions to the 64bits variants? |
| 9 |
> > > > |
| 10 |
> > > > No, because that can easily break ABI of programs that actually |
| 11 |
> > > > want the non-LFS one (for instance anything that wraps around |
| 12 |
> > > > function calls, including but not limited to padsp, aoss, and |
| 13 |
> > > > similar wrappers.) |
| 14 |
> > > |
| 15 |
> > > This seems easily fixed with an opt-out for lfs flags that such |
| 16 |
> > > programs can use. They'll need to be touched to disable the QA |
| 17 |
> > > warning anyway. |
| 18 |
> > |
| 19 |
> > this is a discussion for upstream toolchain packages (largely glibc) |
| 20 |
> > and in fact i started such a heretical thread over a year ago. it |
| 21 |
> > was not well received due to the implicit/silent ABI change that new |
| 22 |
> > builds would receive. glibc likes to be conservative as it is the |
| 23 |
> > foundation of everything. |
| 24 |
> > |
| 25 |
> > so unless glibc changes, updating our copy of glibc would only |
| 26 |
> > somewhat help our users. conversely, getting the changes pushed to |
| 27 |
> > the respective upstream would help everyone. |
| 28 |
> |
| 29 |
> I'm not sure what's best for every one: |
| 30 |
> 1. Push hundreds of patches upstream to add lfs flags; |
| 31 |
> 2. Apply your patch to our glibc ebuilds, fix the corner cases, and go |
| 32 |
> back to glibc upstream with these data. |
| 33 |
> |
| 34 |
> Least to say is that I'm not a big fan of lfs flags as done in glibc and |
| 35 |
> I certainly prefer 2., but you'd know better. |
| 36 |
|
| 37 |
well if we're going to do arbitrary lists ;) |
| 38 |
(1) your options aren't mutually exclusive |
| 39 |
(2) implementing both are desirable |
| 40 |
(3) considering the glibc effort has been stalled for over a year, (1) is |
| 41 |
something we can help accomplish and make reasonable progress on |
| 42 |
(4) glibc isn't the only one that implements LFS in a transparent backwards |
| 43 |
compatible manner |
| 44 |
|
| 45 |
which leads me to the next part ... my first suggestion in the tracker is for |
| 46 |
autotool based projects to use AC_SYS_LARGEFILE because: |
| 47 |
(a) it supports a variety of systems |
| 48 |
(b) as new systems come up or bugs are found or whatever, the autoconf macro |
| 49 |
will improve and people eventually get those fixes for free |
| 50 |
(c) it does it all transparently for you -- add the macro and you're done |
| 51 |
(d) it fixes the package for all users, new & old |
| 52 |
|
| 53 |
the reason i listed only the raw CPPFLAGS and autoconf macros are because those |
| 54 |
are the two i'm familiar with. i don't know how other build systems (e.g. |
| 55 |
cmake) support this (assuming they do at all). if people have other recipes on |
| 56 |
hand, then it would be great to collect more there. |
| 57 |
-mike |
Archives