Adhemerval Zanella Netto writes: > On 17/07/23 14:31, Sam James wrote: >> >> Adhemerval Zanella Netto writes: >> >>> On 17/07/23 12:01, Sam James wrote: >>>> >>>> Adhemerval Zanella via Libc-alpha writes: >>>> >>>>> The libcrypt was maked to phase out on 2.28, and better projects >>>>> already exist that provide both compatibility and better API >>>>> (libxcrypt). The sparc optimizations add the burden to extra >>>>> build-many-glibcs.py configurations. >>>>> >>>> >>>> I guess. I'd personally prefer just removing it all when libcrypt >>>> is removed, not hacking away at it beforehand. >>> >>> I don't think we will ever be able to remove libgcrypt due compat reason. >>> Maybe we can make crypt return ENOSYS as default, but even though I think >>> if libcrypt is still enabled we will need to keep old code as compat >>> layer. >>> >> >> In the other thread, we're talking about when it's time to kill it >> entirely (I suppose just the option to build, not the real >> implementation). > > I am not sure what kind of compatibility we will need to preserve for > libcrypto. For sunrpc 5500cdba401), we have removed most of the symbols > but still kept some old ones for compatibility even though the > libtirpc does implement such symbols (like key_setsecret for instance). > > It seems that libcrypto is way simpler, and libxcrypt does implement > all require symbol version which the expected. So it should be doable. > >> >> My assumption was we'd remove optimisations like this at that point. > > The idea of the patch is to streamline the required build coverage to > avoid having a --enable-crypt just for sparc. Sure we can pack if/when > we remove libcrypto, but I think this is orthogonal. You feel strongly so it's fine with me to yank it then, I just felt it was cleaner to not "soft-kill" it before it was removed, but you're right that it's unclear how we're even going to remove it and how far. Objection withdrawn - thanks!