| 1 |
Dnia 2014-12-08, o godz. 09:56:11 |
| 2 |
Alexis Ballier <aballier@g.o> napisał(a): |
| 3 |
|
| 4 |
> On Sun, 7 Dec 2014 11:37:57 +0100 |
| 5 |
> Michał Górny <mgorny@g.o> wrote: |
| 6 |
> |
| 7 |
> > 1. No cross-compilation support. If the project proves being a success |
| 8 |
> > it will be readded at some point. However, I will likely fork glibc |
| 9 |
> > first and work on a sane crossdev alternative. |
| 10 |
> |
| 11 |
> Could you please elaborate on this ? |
| 12 |
> How and why this broke, what is wrong in glibc, what would be a "sane |
| 13 |
> crossdev alternative" and how crossdev is not. |
| 14 |
|
| 15 |
1. eblits are broken in glibc. Another case of incorrect interpretation |
| 16 |
of code sharing with love for breaking stable ebuilds. Plus I'd love to |
| 17 |
add multilib flags to it but we'll likely doing that to main glibc as |
| 18 |
well soon, if eblits don't get into our way. |
| 19 |
|
| 20 |
2. crossdev is broken because it creates semi-random, unmaintained |
| 21 |
ebuilds in randomly chosen overlay, those ebuilds relying on |
| 22 |
toolchain.eclass behavior. |
| 23 |
|
| 24 |
3. I don't have any real alternative design yet. However, one |
| 25 |
of the first ideas of changing crossdev is to replace copying ebuilds |
| 26 |
with symlinking gcc ebuild directory. This will at least ensure proper |
| 27 |
sync between real ebuilds and cross-ebuilds. |
| 28 |
|
| 29 |
-- |
| 30 |
Best regards, |
| 31 |
Michał Górny |
Archives