[PATCH] Raise the minimum binutils version to 2.39

[Stefan Liebler]

On 4/9/25 17:54, H.J. Lu wrote:
> On Mon, Apr 7, 2025 at 8:28 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> On Mon, Apr 7, 2025 at 6:32 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> * Stefan Liebler:
>>>
>>>> The recent commit 27b96e069aad17cefea9437542180bff448ac3a0 raises the minimum
>>>> GCC version to 12.1 which was released in 2022.
>>>>
>>>> The current minimum bintuils version 2.25 was released end of 2014.  This patch
>>>> now raises the minimum binutils version to 2.39 which was also released in 2022.
>>>>
>>>> For ARC and powerpc, the special checks/hints are not needed anymore.
>>>>
>>>> On s390x, the used cfi_escape for cfi_val_offset can now be ommitted.
>>>>
>>>> In sysdeps/[alpha|hppa|csky]/configure.ac, PIE is unsupported with this comment:
>>>> PIE builds fail on binutils 2.37 and earlier, see:
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=28672
>>>> This patch keeps PIE unsupported and let the machine maintainers test and
>>>> enable it later.
>>>>
>>>> In sysdeps/arm/configure.ac, there is a check whether TPOFF relocs with addends
>>>> are assembled correctly, which is known to be broken in binutils 2.24 and 2.25.
>>>> See: https://sourceware.org/bugzilla/show_bug.cgi?id=18383
>>>> This patch keeps the check as is and let the machine maintainers check if it
>>>> still required.
>>>
>>> The risk here is that this binutils version introduces new relocation
>>> types into the crt*.o files (or libc_nonshared.a or even libc.a) that
>>> cannot be handled by older binutils.  This is different from bumping the
>>> GCC requirement, which usually does not impose a compiler upgrade after
>>> installing glibc.
Thus this case would be if a distribution uses an older binutils version
by default, but a recent glibc version, which was built with a newer not
shipped binutils version? Then there are new relocation types in
crt*.o/... files, which can't be handled by the older system binutils
version.

Do you have specific relocation types in mind? I assume those are then
architecture specific? Perhaps we can at least bump the minimum version
to just before the version where those new relocation types were introduced?

On the other hand, how can we then bump the requirements in future at all?
>>
>> Good point.   Do we have tests to check such things?
>>
>>> Certain binutils versions even treat unknown relocation types as type 0,
>>> leading to very difficult-to-debug misbehavior (unless you happen to
>>> recall that you have seen this before …).
> 
> Is this a real problem?  It can happen without raising the minimum binutils
> version since glibc may be built with much newer binutils today.
True, distributions or others could have this situation even without
this patch.
Are there known reasons why to use newer glibc/gcc versions, but keep an
old binutils version?