| 1 |
On Monday, March 07, 2011 12:35:53 Thomas Sachau wrote: |
| 2 |
> Am 07.03.2011 11:24, schrieb Mike Frysinger: |
| 3 |
> > also, i'll be converting the glibc ebuilds do always invoke the |
| 4 |
> > multilib_env helper functions. this will allow us to drop the |
| 5 |
> > {C,LD}FLAGS_xxx and friends from profiles since glibc was the main |
| 6 |
> > consumer. i imagine this inadvertently break some other packages, so |
| 7 |
> > if people want to test this on their own systems before i make the |
| 8 |
> > commit, that'd be cool. the plan would be for said breakage will go |
| 9 |
> > through bugzilla to get the ebuild updated rather than reverting the |
| 10 |
> > profile. |
| 11 |
> |
| 12 |
> Please leave those vars in the profile, i depend on them in |
| 13 |
> multilib-portage to crosscompile e.g. for x86 on the amd64 profile. If you |
| 14 |
> remove them now, they would be re-added again once multilib-portage (and |
| 15 |
> the related EAPI) become official, so imho we can just leave them in for |
| 16 |
> now. |
| 17 |
|
| 18 |
these need to be centralized somehow. duplicating multilib.eclass and the |
| 19 |
profiles indefinitely isnt going to fly. |
| 20 |
|
| 21 |
perhaps we unify all the multilib settings into one file such as |
| 22 |
base/make.defaults ... that would require normalizing of the ABI value across |
| 23 |
all targets, but i dont think that's an issue. |
| 24 |
-mike |
Archives