| 1 |
I'm a bit surprised about this discussion as Mike, who currently |
| 2 |
maintains the toolchain, has never implied that suddenly older versions |
| 3 |
of glibc are unusable. Or that we need a big cleanup. |
| 4 |
|
| 5 |
He simply stated two facts (that have been true for a long time) |
| 6 |
|
| 7 |
- for a current kernel a current toolchain is necessary and vice versa. |
| 8 |
|
| 9 |
- we support older versions of glibc (gcc/etc.) mainly for crossdev |
| 10 |
(and some other special purposes) on a best effort basis without any |
| 11 |
usability or security guarantees. |
| 12 |
|
| 13 |
The latter implies that you should not actively use them in your regular |
| 14 |
Gentoo setup, not that they must be removed from the tree. |
| 15 |
|
| 16 |
> [...] |
| 17 |
> |
| 18 |
> Crossdev was mentioned in discussions on irc, but again it wasn't clear |
| 19 |
> to me why specific versions of glibc are needed. I don't know of any |
| 20 |
> hard dependencies in the portage tree like that. |
| 21 |
|
| 22 |
Again, |
| 23 |
|
| 24 |
just the simple fact that crossdev without the ability to select |
| 25 |
specific versions of glibc is only half as useful. And please, do not |
| 26 |
underestimate the usefulness of our crossdev script in this regard! |
| 27 |
|
| 28 |
Because you're arguing that no example was presented: |
| 29 |
E.g. I've an embedded armv7a-hardfloat board which ships with glibc |
| 30 |
2.16 (This is a concrete example and not a vague "some users might need |
| 31 |
it".). I want to have a cross compile environment for it to compile some |
| 32 |
specific software (not a complete userland). I do not want to replace |
| 33 |
the userland/ship a custom sysroot/use an LD_LIBRARY_PATH hack, so I'm |
| 34 |
basically forced to compile with a glibc of at most 2.16 (otherwise you |
| 35 |
get symbol lookup errors.) |
| 36 |
|
| 37 |
|
| 38 |
To ease the maintenance burden there are multiple possibilities to |
| 39 |
tackle it without removing old glibc versions altogether: |
| 40 |
|
| 41 |
- We could debundle newer glibc versions from toolchain.eclass/eblits |
| 42 |
|
| 43 |
- We could migrate older versions in a dedicated overlay with some |
| 44 |
sort of versioned toolchain.eclass/eblits. (same for the other |
| 45 |
canonical packages). |
| 46 |
|
| 47 |
Further, if the fact that specific versions are unmaintained (and do not |
| 48 |
get any security backports) it is also possible to just drop keywords. |
| 49 |
|
| 50 |
|
| 51 |
Best, |
| 52 |
Matthias |
Archives