[PATCH] gas: Fix -mrelax-relocations detection on Solaris/x86 [PR19520]

[Jan Beulich]

On 28.09.2025 16:16, Rainer Orth wrote:
> I recently noticed a complex case statement in gas/configure.ac controlling
> the setting of ac_default_x86_relax_relocations on Solaris/x86.  Since it
> included all versions of Solaris, it could be massively simplified.
> 
> Looking closer however, I found that it was introduced in
> 
> commit 0cb4071ef9e10f703220f5e731141bf438aca16e
> Author: H.J. Lu <hjl.tools@gmail.com>
> Date:   Wed Feb 3 08:25:15 2016 -0800
> 
>     Add -mrelax-relocations= to x86 assembler
> 
> based on PR gas/19520.  This PR reported that the new R_386_GOT32X
> etc. relocations weren't supported on older versions of Solaris,
> breaking gcc bootstrap.  In response, they were disabled on all Solaris
> versions except Solaris 12, where they had been implemented in the
> native toolchain based on my findings.
> 
> However, Solaris 12 has been rechristened to 11.4 before release,
> effectively disabling DEFAULT_GENERATE_X86_RELAX_RELOCATIONS on all
> versions of Solaris/x86.
> 
> This patch fixes this by correcting the detection of Solaris 11.4.  Since
> the minor version is not included in the configure triplet, this can only
> be done natively with uname -v.
> 
> Tested on i386-pc-solaris2.11 and amd64-pc-solaris2.11 (Solaris 11.4)
> and with gcc trunk bootstraps with the patched gas and native ld.  Also
> tested on Solaris 11.3/x86 (build only to check that the macro is set to
> 0 as expected).
> 
> Ok for trunk?

Hmm, no, not really. What target an assembler is built for shouldn't
really depend on host properties imo. There's no other similar use
of uname anywhere in the script.

> However, given that the support has effectively been disabled on Solaris
> since the release of Solaris 11.4 back in 2018, I wonder if it wouldn't
> be better to simplify things massively: rip out the
> --enable-x86-relax-relocations configure option together with
> -mrelax-relocations (either silently ignoring it or rejecting it), at
> the same time disabling the support on Solaris completely as it has been
> for the last 7 years.

This may be an option, but H.J. - could you please comment here?

Jan