I'm a bit surprised about this discussion as Mike, who currently
maintains the toolchain, has never implied that suddenly older versions
of glibc are unusable. Or that we need a big cleanup.

He simply stated two facts (that have been true for a long time)

 - for a current kernel a current toolchain is necessary and vice versa.

 - we support older versions of glibc (gcc/etc.) mainly for crossdev
   (and some other special purposes) on a best effort basis without any
   usability or security guarantees.

The latter implies that you should not actively use them in your regular
Gentoo setup, not that they must be removed from the tree.

> [...]
>
> Crossdev was mentioned in discussions on irc, but again it wasn't clear
> to me why specific versions of glibc are needed. I don't know of any
> hard dependencies in the portage tree like that.

Again,

just the simple fact that crossdev without the ability to select
specific versions of glibc is only half as useful. And please, do not
underestimate the usefulness of our crossdev script in this regard!

Because you're arguing that no example was presented:
E.g. I've an embedded armv7a-hardfloat board which ships with glibc
2.16 (This is a concrete example and not a vague "some users might need
it".). I want to have a cross compile environment for it to compile some
specific software (not a complete userland). I do not want to replace
the userland/ship a custom sysroot/use an LD_LIBRARY_PATH hack, so I'm
basically forced to compile with a glibc of at most 2.16 (otherwise you
get symbol lookup errors.)


To ease the maintenance burden there are multiple possibilities to
tackle it without removing old glibc versions altogether:

  - We could debundle newer glibc versions from toolchain.eclass/eblits

  - We could migrate older versions in a dedicated overlay with some
    sort of versioned toolchain.eclass/eblits. (same for the other
    canonical packages).

Further, if the fact that specific versions are unmaintained (and do not
get any security backports) it is also possible to just drop keywords.


Best,
Matthias

Attachment: signature.asc
Description: PGP signature

Reply via email to