On Tue, Aug 6, 2024, at 16:27, John Paul Adrian Glaubitz wrote:
> On Tue, 2024-08-06 at 16:21 +0200, Arnd Bergmann wrote:
>> Most of issues with armel packages are about libatomic link
>> time requirements, and about applications that hardcode armv7
>> or vfp instruction extensions.
>
> Code that hardwires CPU baselines is considered RC-buggy anyway, so
> that shouldn't be an argument. And that notoric libatomic issue is
> just something that should be finally fixed in GCC upstream (unless
> I am missing something why that can't be done).
Right, in principle none of this is specific to armel, but
I think this one gets noticed more than the others:
- upstream projects are likely to hardwire armv7 assembly for
arm32 than hitting the same problem on other architectures
since most people don't understand the exact cpu specific
requirements, and armv7 is what everyone has.
- for libatomic, I think it's the only remaining official
port that is affected (not sure about mips64el), while a
number of the inofficial ones likely have the same issue
(parisc, sparc, ...).
If none of the official release architectures had
the libatomic issue, it would make life a little easier
for their maintainers, but it makes maintaining the
non-release architectures harder because then fewer
people care.
I don't know if a gcc change can address all of the
libatomic issues, but that would of course be best.
Arnd
