Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Florian Weimer <fweimer@redhat.com>]

* Michael Matz via Libc-alpha:

> Hey,
>
> On Tue, 12 Jul 2022, Adhemerval Zanella Netto via Binutils wrote:
>
>>  * Fix the R_LARCH_NONE generation and backport it to 2.38, or bump
>>    the minimum required version to 2.39.  This will hold any inclusion
>>    on glibc until binutils is fixed.
>> 
>>  * Add R_LARCH_NONE handling in boostraping. This is a simpler solution
>>    and although it might hinder some possible bugs in static linker,
>>    I think for current port status it the best option.
>
> Postel's law is always good advise.  "Be strict in what you generate, be 
> lenient in what you accept", even more so for something so basic as a 
> program loader.  It seems ill-advised to use ld.so to force something 
> onto users that can only be called a strive for purity.

The problem here is that R_*_NONE has historically been used in binutils
to indicate, “I did not recognize the relocation in the input file”,
while still generating an output file.  And missing run-time relocations
can be quite challenging to diagnose.  In a sense, the loader has to
reject R_*_NONE relocations to avoid generating bogus relocated data.

Thanks,
Florian