Re: Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
On 2020-04-21 18:37, Noah Meyerhans wrote:
> > To be honest from a glibc maintenance point of view it's something I
> > would like to avoid. We haven't been actively trying to remove the
> > remaining optimized libraries (on i386, hurd and alpha), but we have
> > tried to avoid adding new ones. The problem is not building a second
> > optimized glibc, but rather providing a safe upgrade as the optimized
> > and the non-optimized package have to be at the same version or one of
> > them has to be disabled. This has caused many system breakages overall.
>
> Understood, that makes sense. I wonder if it's worth it to investigate
> techniques to improve the situation around optimized libraries. Do you
> have any thoughts on what such an improvement might look like?
The hardware capabilities system works fine upstream, but doesn't work
for us because:
1) we want to be able to upgrade major upstream version online (as
opposed to fedora for example)
2) we ship the optimized libraries in a different package
The various libc librairies need to have the same version at any time,
this is especially true for ld.so vs libc.so. As we do not upgrade the
default libc and the optimized one exactly at the same time (they are in
different packages), we upgrade first the default libc and then we have
the Debian specific nohwcap mechanism to prevent using the optimize
library until it has also been upgraded.
One solution for this would be to ship the optimized library in the same
package as the default library. Now this is not acceptable for embedded
systems as they might not need that library and can't remove it. This is
even more problematic if we need to add more optimized libraries. I guess
this might be the case for arm64 as there are many new extensions in the
pipe.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: