Cleanup bfd target vectors and ld emulations on Solaris

  This patch is a major cleanup of the Solaris configurations of both bfd and ld.

The Solaris cases in both bfd/config.bfd and ld/configure.tgt have seen a
major cleanup, making the support for various Solaris versions explicit,
correcting several inconsistencies, and making it easier to remove support
for some versions in the future.

* All 32-bit-only configurations (Solaris < 7 on SPARC, Solaris < 10 on
  x86) only include the 32-bit target vectors and linker emulations.

* For 32-bit-default targets on 64-bit systems (Solaris >= 7 on SPARC,
  Solaris >= 10 on x86), the 32-bit target vectors and linker emulations
  are the default while supporting the 64-bit ones.

* For 64-bit-default targets on 64-bit systems, it's the other way round.
  They default to 64-bit target vectors etc. while also supporting the
  32-bit ones.

* On x86, the iamcu target vectors and linker emulations have been
  removed: Solaris never supported the Intel MCU.

* On x86, the PE and PEI target vectors have been removed: they were only
  supported in binutils proper.  Their only use would be on EFI files
  e.g. in GRUB, which doesn't justify their inclusion.

* With iamcu support gone, a few gas tests had to be disabled as on
  VxWorks.

* The 32-bit Solaris/x86 ld configuration currently includes the
  elf_i386_ldso emulation, which was never a emulation in its own right but
  just an implementation detail of the elf_i386_sol2 emulation.  Instead,
  the settings that are not already provided by sourced .sh files are moved
  into elf_i386_sol2.sh.  Many settings became superfluous by just sourcing
  elf_i386.sh as is already done in elf_x86_64_sol2.sh, massively
  simplifying the emulation.

* Solaris-specific settings in generic emulparams scripts have been moved
  to the *_sol2.sh files.

* NATIVE_LIB_DIRS in ld/configure.tgt now uses the default setting:
  /usr/ccs/lib contains just a bunch of symlinks into /usr/lib at least
  since Solaris 8.

* ld/emulparams/solaris2.sh now sets ELF_INTERPRETER_NAME to
  /usr/lib/amd64/ld.so.1, matching both the native linker and
  elf_i386_sol2.sh.

* The SEARCH_DIR statements in linker scripts on 64-bit targets contained
  both the native (64-bit) and non-default (32-bit) directies.  The latter
  are completely pointless and are omitted using a new
  LIBPATH_SKIP_NONNATIVE setting.

Tested on {amd64,i386}-pc-solaris2.11 and {sparcv9,sparc}-sun-solaris2.11,
and {x86_64,i686}-pc-linux-gnu as well as with gcc trunk bootstraps on the
Solaris targets.  On those, I've compared the gas/ld and gas/gld 2.45.50
testresults with 2.45 ones.

Ok for trunk?

	Rainer
  

On 01.12.2025 14:31, Rainer Orth wrote:
> This patch is a major cleanup of the Solaris configurations of both bfd and ld.
> 
> The Solaris cases in both bfd/config.bfd and ld/configure.tgt have seen a
> major cleanup, making the support for various Solaris versions explicit,
> correcting several inconsistencies, and making it easier to remove support
> for some versions in the future.
> 
> * All 32-bit-only configurations (Solaris < 7 on SPARC, Solaris < 10 on
>   x86) only include the 32-bit target vectors and linker emulations.
> 
> * For 32-bit-default targets on 64-bit systems (Solaris >= 7 on SPARC,
>   Solaris >= 10 on x86), the 32-bit target vectors and linker emulations
>   are the default while supporting the 64-bit ones.
> 
> * For 64-bit-default targets on 64-bit systems, it's the other way round.
>   They default to 64-bit target vectors etc. while also supporting the
>   32-bit ones.

These having had the 32-bit vectors as default was pretty certainly wrong.
I think this being a (perhaps significant) change may want making more
apparent here. (I'd like to note that with this adjustment I wouldn't even
have noticed an issue that my first attempt to deal with the two linker
testcase FAILs caused.)

> * On x86, the iamcu target vectors and linker emulations have been
>   removed: Solaris never supported the Intel MCU.
> 
> * On x86, the PE and PEI target vectors have been removed: they were only
>   supported in binutils proper.  Their only use would be on EFI files
>   e.g. in GRUB, which doesn't justify their inclusion.
> 
> * With iamcu support gone, a few gas tests had to be disabled as on
>   VxWorks.
> 
> * The 32-bit Solaris/x86 ld configuration currently includes the
>   elf_i386_ldso emulation, which was never a emulation in its own right but
>   just an implementation detail of the elf_i386_sol2 emulation.  Instead,
>   the settings that are not already provided by sourced .sh files are moved
>   into elf_i386_sol2.sh.  Many settings became superfluous by just sourcing
>   elf_i386.sh as is already done in elf_x86_64_sol2.sh, massively
>   simplifying the emulation.
> 
> * Solaris-specific settings in generic emulparams scripts have been moved
>   to the *_sol2.sh files.
> 
> * NATIVE_LIB_DIRS in ld/configure.tgt now uses the default setting:
>   /usr/ccs/lib contains just a bunch of symlinks into /usr/lib at least
>   since Solaris 8.
> 
> * ld/emulparams/solaris2.sh now sets ELF_INTERPRETER_NAME to
>   /usr/lib/amd64/ld.so.1, matching both the native linker and
>   elf_i386_sol2.sh.
> 
> * The SEARCH_DIR statements in linker scripts on 64-bit targets contained
>   both the native (64-bit) and non-default (32-bit) directies.  The latter
>   are completely pointless and are omitted using a new
>   LIBPATH_SKIP_NONNATIVE setting.
> 
> Tested on {amd64,i386}-pc-solaris2.11 and {sparcv9,sparc}-sun-solaris2.11,
> and {x86_64,i686}-pc-linux-gnu as well as with gcc trunk bootstraps on the
> Solaris targets.  On those, I've compared the gas/ld and gas/gld 2.45.50
> testresults with 2.45 ones.
> 
> Ok for trunk?

Yes, albeit ideally with a few small adjustments:
- The "want64=true" looks bogus for i[3-7]86-*-solaris2.1[01]*, i.e. likely
  wants removing while bringing things into consistent shape.
- The x86_64-*-solaris2.1[01]* entry would preferably move down to the other
  x86_64-*-* entries.
- While in comments you mention PR 27666, nothing at all is said about this
  aspect in the description.

Jan
  

Hi Jan,

sorry for the late reply: I've been swamped at work lately.

> On 01.12.2025 14:31, Rainer Orth wrote:
>> * For 64-bit-default targets on 64-bit systems, it's the other way round.
>>   They default to 64-bit target vectors etc. while also supporting the
>>   32-bit ones.
>
> These having had the 32-bit vectors as default was pretty certainly wrong.
> I think this being a (perhaps significant) change may want making more
> apparent here. (I'd like to note that with this adjustment I wouldn't even
> have noticed an issue that my first attempt to deal with the two linker
> testcase FAILs caused.)

I don't really think this matters: the compiler drivers (gcc and clang)
always specify the emulation explicitly, so won't be affected by the
change of default.  The same is true for libtool which also invokes the
linker under the hood.  Otherwise, the linker would only be called
directly to get complete control over the link without the need for
everything the drivers do, like add crts, special options
(e.g. --eh-frame) etc.  Outside the binutils testsuite, that would only
be something like linking the kernel, which gld isn't up to due to many
Solaris-specific features it lacks, like support for kernel modules.

>> Ok for trunk?
>
> Yes, albeit ideally with a few small adjustments:
> - The "want64=true" looks bogus for i[3-7]86-*-solaris2.1[01]*, i.e. likely
>   wants removing while bringing things into consistent shape.

IIUC, want64=true is needed whenever a configuration includes 64-bit
target vectors, which is true in this case (gcc is always bi-arch if the
OS supports it, so expects the same from gld).  The Solaris 10+/i386
case is identical to what's done for Solaris 7+/sparc in this regard.

> - The x86_64-*-solaris2.1[01]* entry would preferably move down to the other
>   x86_64-*-* entries.

Done (although I missed that part in the initial commit, will fix up
immediately).

I noticed that may i?86-*-* targets are listed below the x86_64-* ones
for some reason, btw.

> - While in comments you mention PR 27666, nothing at all is said about this
>   aspect in the description.

Done.

Thanks.
	Rainer
  

On 11.12.2025 14:58, Rainer Orth wrote:
>> On 01.12.2025 14:31, Rainer Orth wrote:
>>> Ok for trunk?
>>
>> Yes, albeit ideally with a few small adjustments:
>> - The "want64=true" looks bogus for i[3-7]86-*-solaris2.1[01]*, i.e. likely
>>   wants removing while bringing things into consistent shape.
> 
> IIUC, want64=true is needed whenever a configuration includes 64-bit
> target vectors, which is true in this case (gcc is always bi-arch if the
> OS supports it, so expects the same from gld).  The Solaris 10+/i386
> case is identical to what's done for Solaris 7+/sparc in this regard.

Not quite: There's targ_selvecs and targ64_selvecs. The latter are included
_if_ BFD64 is enabled anyway. "want64" aiui should be set only if
targ_selvecs includes any 64-bit arch.

Jan
  

Hi Jan,

> On 11.12.2025 14:58, Rainer Orth wrote:
>>> On 01.12.2025 14:31, Rainer Orth wrote:
>>>> Ok for trunk?
>>>
>>> Yes, albeit ideally with a few small adjustments:
>>> - The "want64=true" looks bogus for i[3-7]86-*-solaris2.1[01]*, i.e. likely
>>>   wants removing while bringing things into consistent shape.
>> 
>> IIUC, want64=true is needed whenever a configuration includes 64-bit
>> target vectors, which is true in this case (gcc is always bi-arch if the
>> OS supports it, so expects the same from gld).  The Solaris 10+/i386
>> case is identical to what's done for Solaris 7+/sparc in this regard.
>
> Not quite: There's targ_selvecs and targ64_selvecs. The latter are included
> _if_ BFD64 is enabled anyway. "want64" aiui should be set only if
> targ_selvecs includes any 64-bit arch.

I see, thanks.  I'll have a look.

However, I find myself constantly confused by both want64 and BFD64,
neither of which is documented in config.bfd.  Maybe you can fix that?

	Rainer
  

On Thu, Dec 11, 2025 at 03:51:39PM +0100, Rainer Orth wrote:
> Hi Jan,
> 
> > On 11.12.2025 14:58, Rainer Orth wrote:
> >>> On 01.12.2025 14:31, Rainer Orth wrote:
> >>>> Ok for trunk?
> >>>
> >>> Yes, albeit ideally with a few small adjustments:
> >>> - The "want64=true" looks bogus for i[3-7]86-*-solaris2.1[01]*, i.e. likely
> >>>   wants removing while bringing things into consistent shape.
> >> 
> >> IIUC, want64=true is needed whenever a configuration includes 64-bit
> >> target vectors, which is true in this case (gcc is always bi-arch if the
> >> OS supports it, so expects the same from gld).  The Solaris 10+/i386
> >> case is identical to what's done for Solaris 7+/sparc in this regard.
> >
> > Not quite: There's targ_selvecs and targ64_selvecs. The latter are included
> > _if_ BFD64 is enabled anyway. "want64" aiui should be set only if
> > targ_selvecs includes any 64-bit arch.
> 
> I see, thanks.  I'll have a look.
> 
> However, I find myself constantly confused by both want64 and BFD64,
> neither of which is documented in config.bfd.  Maybe you can fix that?

The BFD64 lines in config.bfd are of course just comments as far as
the shell is concerned.  They are used to generate a list of target
vectors.  See targmatch.sed and targmatch.h in targets.c.

Regarding the solaris cleanup, I've been testing these two cross
targets as part of my regression runs: "amd64-pc-solaris2.11" and
"sparc-sun-solaris2".  The latter config slips past the obsolescence
check in config.bfd and matches sparc*-*-*, and results in
"Fatal error: selected target format 'elf32-sparc-sol2' unknown"
from gas.

Here's what I propose to tidy this.  I'll commit it on your OK.

commit 211f1c2f96c84b8af8596ab9d8798c063214e127
Author: Alan Modra <amodra@gmail.com>
Date:   Fri Dec 12 15:00:25 2025 +1030

    more solaris tidies
    
    Don't overspecify the obsolete solaris targets: match solaris* rather
    than solaris2.[0-9]*.  Move the sparc-*-solaris2.[0-6]* match later,
    and make it sparc*-*-solaris* so that it catches sparcv9 and sparc64.

diff --git a/bfd/config.bfd b/bfd/config.bfd
index a9f5f457f45..b180382d7f4 100644
--- a/bfd/config.bfd
+++ b/bfd/config.bfd
@@ -51,7 +51,7 @@ case $targ in
  *-*-solaris2.1[01]*)
     # Only Solaris 10+ is not obsolete.
     ;;
- *-*-solaris2.[0-9]* | \
+ *-*-solaris* | \
  null)
     if test "x$enable_obsolete" != xyes; then
       echo "*** Configuration $targ is obsolete." >&2
@@ -600,7 +600,7 @@ case "${targ}" in
     targ64_selvecs=x86_64_elf64_sol2_vec
     want64=true
     ;;
-  i[3-7]86-*-solaris2.[0-9]*)
+  i[3-7]86-*-solaris*)
     # PR 27666: Do not include i386_elf32_vec here.
     targ_defvec=i386_elf32_sol2_vec
     ;;
@@ -1341,10 +1341,6 @@ case "${targ}" in
     targ64_selvecs=sparc_elf64_sol2_vec
     want64=true
     ;;
-  sparc-*-solaris2.[0-6]*)
-    # PR 27666: Do not include sparc_elf32_vec here.
-    targ_defvec=sparc_elf32_sol2_vec
-    ;;
 #ifdef BFD64
   sparcv9-*-solaris2.[7-9]* | sparcv9-*-solaris2.1[01]* | \
   sparc64-*-solaris2.[7-9]* | sparc64-*-solaris2.1[01]*)
@@ -1376,6 +1372,10 @@ case "${targ}" in
     targ_defvec=sparc_elf32_vxworks_vec
     targ_selvecs="sparc_elf32_vec"
     ;;
+  sparc*-*-solaris*)
+    # PR 27666: Do not include sparc_elf32_vec here.
+    targ_defvec=sparc_elf32_sol2_vec
+    ;;
   sparc*-*-*)
     targ_defvec=sparc_elf32_vec
     ;;
diff --git a/ld/po/BLD-POTFILES.in b/ld/po/BLD-POTFILES.in
index 94bd7b0d2a8..d7d0c517307 100644
--- a/ld/po/BLD-POTFILES.in
+++ b/ld/po/BLD-POTFILES.in
@@ -204,7 +204,6 @@ eelf_i386.c
 eelf_i386_be.c
 eelf_i386_fbsd.c
 eelf_i386_haiku.c
-eelf_i386_ldso.c
 eelf_i386_sol2.c
 eelf_i386_vxworks.c
 eelf_iamcu.c
  

On 12.12.2025 05:40, Alan Modra wrote:
> On Thu, Dec 11, 2025 at 03:51:39PM +0100, Rainer Orth wrote:
>> Hi Jan,
>>
>>> On 11.12.2025 14:58, Rainer Orth wrote:
>>>>> On 01.12.2025 14:31, Rainer Orth wrote:
>>>>>> Ok for trunk?
>>>>>
>>>>> Yes, albeit ideally with a few small adjustments:
>>>>> - The "want64=true" looks bogus for i[3-7]86-*-solaris2.1[01]*, i.e. likely
>>>>>   wants removing while bringing things into consistent shape.
>>>>
>>>> IIUC, want64=true is needed whenever a configuration includes 64-bit
>>>> target vectors, which is true in this case (gcc is always bi-arch if the
>>>> OS supports it, so expects the same from gld).  The Solaris 10+/i386
>>>> case is identical to what's done for Solaris 7+/sparc in this regard.
>>>
>>> Not quite: There's targ_selvecs and targ64_selvecs. The latter are included
>>> _if_ BFD64 is enabled anyway. "want64" aiui should be set only if
>>> targ_selvecs includes any 64-bit arch.
>>
>> I see, thanks.  I'll have a look.
>>
>> However, I find myself constantly confused by both want64 and BFD64,
>> neither of which is documented in config.bfd.  Maybe you can fix that?
> 
> The BFD64 lines in config.bfd are of course just comments as far as
> the shell is concerned.  They are used to generate a list of target
> vectors.  See targmatch.sed and targmatch.h in targets.c.
> 
> Regarding the solaris cleanup, I've been testing these two cross
> targets as part of my regression runs: "amd64-pc-solaris2.11" and
> "sparc-sun-solaris2".  The latter config slips past the obsolescence
> check in config.bfd and matches sparc*-*-*, and results in
> "Fatal error: selected target format 'elf32-sparc-sol2' unknown"
> from gas.
> 
> Here's what I propose to tidy this.  I'll commit it on your OK.

But weren't *-*-solaris2 supposed to continue to work, kind of as a
wildcard for *-*-solaris2.1* ? I'm, too, having
targets of that form in my set used for "global" testing.

Jan

> commit 211f1c2f96c84b8af8596ab9d8798c063214e127
> Author: Alan Modra <amodra@gmail.com>
> Date:   Fri Dec 12 15:00:25 2025 +1030
> 
>     more solaris tidies
>     
>     Don't overspecify the obsolete solaris targets: match solaris* rather
>     than solaris2.[0-9]*.  Move the sparc-*-solaris2.[0-6]* match later,
>     and make it sparc*-*-solaris* so that it catches sparcv9 and sparc64.
> 
> diff --git a/bfd/config.bfd b/bfd/config.bfd
> index a9f5f457f45..b180382d7f4 100644
> --- a/bfd/config.bfd
> +++ b/bfd/config.bfd
> @@ -51,7 +51,7 @@ case $targ in
>   *-*-solaris2.1[01]*)
>      # Only Solaris 10+ is not obsolete.
>      ;;
> - *-*-solaris2.[0-9]* | \
> + *-*-solaris* | \
>   null)
>      if test "x$enable_obsolete" != xyes; then
>        echo "*** Configuration $targ is obsolete." >&2
> @@ -600,7 +600,7 @@ case "${targ}" in
>      targ64_selvecs=x86_64_elf64_sol2_vec
>      want64=true
>      ;;
> -  i[3-7]86-*-solaris2.[0-9]*)
> +  i[3-7]86-*-solaris*)
>      # PR 27666: Do not include i386_elf32_vec here.
>      targ_defvec=i386_elf32_sol2_vec
>      ;;
> @@ -1341,10 +1341,6 @@ case "${targ}" in
>      targ64_selvecs=sparc_elf64_sol2_vec
>      want64=true
>      ;;
> -  sparc-*-solaris2.[0-6]*)
> -    # PR 27666: Do not include sparc_elf32_vec here.
> -    targ_defvec=sparc_elf32_sol2_vec
> -    ;;
>  #ifdef BFD64
>    sparcv9-*-solaris2.[7-9]* | sparcv9-*-solaris2.1[01]* | \
>    sparc64-*-solaris2.[7-9]* | sparc64-*-solaris2.1[01]*)
> @@ -1376,6 +1372,10 @@ case "${targ}" in
>      targ_defvec=sparc_elf32_vxworks_vec
>      targ_selvecs="sparc_elf32_vec"
>      ;;
> +  sparc*-*-solaris*)
> +    # PR 27666: Do not include sparc_elf32_vec here.
> +    targ_defvec=sparc_elf32_sol2_vec
> +    ;;
>    sparc*-*-*)
>      targ_defvec=sparc_elf32_vec
>      ;;
> diff --git a/ld/po/BLD-POTFILES.in b/ld/po/BLD-POTFILES.in
> index 94bd7b0d2a8..d7d0c517307 100644
> --- a/ld/po/BLD-POTFILES.in
> +++ b/ld/po/BLD-POTFILES.in
> @@ -204,7 +204,6 @@ eelf_i386.c
>  eelf_i386_be.c
>  eelf_i386_fbsd.c
>  eelf_i386_haiku.c
> -eelf_i386_ldso.c
>  eelf_i386_sol2.c
>  eelf_i386_vxworks.c
>  eelf_iamcu.c
>
  

Hi Jan,

>> Regarding the solaris cleanup, I've been testing these two cross
>> targets as part of my regression runs: "amd64-pc-solaris2.11" and
>> "sparc-sun-solaris2".  The latter config slips past the obsolescence
>> check in config.bfd and matches sparc*-*-*, and results in
>> "Fatal error: selected target format 'elf32-sparc-sol2' unknown"
>> from gas.
>> 
>> Here's what I propose to tidy this.  I'll commit it on your OK.
>
> But weren't *-*-solaris2 supposed to continue to work, kind of as a
> wildcard for *-*-solaris2.1* ? I'm, too, having
> targets of that form in my set used for "global" testing.

I'd rather not do such silent under-the-hood aliasing if it can be
avoided.  I'd rather match what GCC's gcc/config.gcc does instead:

# Unsupported targets list.  Do not put an entry in this list unless
# it would otherwise be caught by a more permissive pattern.  The list
# should be in alphabetical order.
case ${target}${target_min} in
[...]
 | *-*-solaris2				\
 | *-*-solaris2.[0-9]			\
 | *-*-solaris2.[0-9].*			\
 | *-*-solaris2.10*			\
 | *-*-solaris2.11.[0-3]*		\
[...]
	echo "*** Configuration ${target}${target_min} not supported" 1>&2
	exit 1

Instead, GCC has contrib/config-list.mk which lists target triples and
optionally configure options to be used in wide-range cross testing.

	Raine
  

On Fri, Dec 12, 2025 at 03:51:31PM +0100, Rainer Orth wrote:
> Hi Jan,
> 
> >> Regarding the solaris cleanup, I've been testing these two cross
> >> targets as part of my regression runs: "amd64-pc-solaris2.11" and
> >> "sparc-sun-solaris2".  The latter config slips past the obsolescence
> >> check in config.bfd and matches sparc*-*-*, and results in
> >> "Fatal error: selected target format 'elf32-sparc-sol2' unknown"
> >> from gas.
> >> 
> >> Here's what I propose to tidy this.  I'll commit it on your OK.
> >
> > But weren't *-*-solaris2 supposed to continue to work, kind of as a
> > wildcard for *-*-solaris2.1* ? I'm, too, having
> > targets of that form in my set used for "global" testing.
> 
> I'd rather not do such silent under-the-hood aliasing if it can be
> avoided.  I'd rather match what GCC's gcc/config.gcc does instead:
> 
> # Unsupported targets list.  Do not put an entry in this list unless
> # it would otherwise be caught by a more permissive pattern.  The list
> # should be in alphabetical order.
> case ${target}${target_min} in
> [...]
>  | *-*-solaris2				\
>  | *-*-solaris2.[0-9]			\
>  | *-*-solaris2.[0-9].*			\
>  | *-*-solaris2.10*			\
>  | *-*-solaris2.11.[0-3]*		\
> [...]
> 	echo "*** Configuration ${target}${target_min} not supported" 1>&2
> 	exit 1

Fair enough, but at the moment we have a consistency problem in
binutils.  There are --target triples that used to work that are still
accepted but result in broken binutils.  I think the following patch
accomplishes your goal regarding solaris2 support more or less
matching gcc, and makes the old targets allowed with --enable-obsolete
consistent.  (The previous patch I posted missed ld/configure.tgt
changes needed for --enable-obsolete.)

BTW, see this solaris3 return from config.guess..
    sun4*:SunOS:6*:*)
	# According to config.sub, this is the proper way to canonicalize
	# SunOS6.  Hard to guess exactly what SunOS6 will be like, but
	# it's likely to be more like Solaris than SunOS4.
	SUN_REL=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`
	GUESS=sparc-sun-solaris3$SUN_REL
	;;


From 07cda2acd71e2c9f7ab9adf58323ac44d09b74d7 Mon Sep 17 00:00:00 2001
From: Alan Modra <amodra@gmail.com>
Date: Fri, 12 Dec 2025 15:00:25 +1030
Subject: more solaris tidies

Don't overspecify the obsolete solaris targets: match solaris* rather
than solaris2.[0-9]*.  Move the sparc-*-solaris2.[0-6]* match later,
and make it sparc*-*-solaris* so that it catches sparcv9 and sparc64.

diff --git a/bfd/config.bfd b/bfd/config.bfd
index a9f5f457f45..b180382d7f4 100644
--- a/bfd/config.bfd
+++ b/bfd/config.bfd
@@ -51,7 +51,7 @@ case $targ in
  *-*-solaris2.1[01]*)
     # Only Solaris 10+ is not obsolete.
     ;;
- *-*-solaris2.[0-9]* | \
+ *-*-solaris* | \
  null)
     if test "x$enable_obsolete" != xyes; then
       echo "*** Configuration $targ is obsolete." >&2
@@ -600,7 +600,7 @@ case "${targ}" in
     targ64_selvecs=x86_64_elf64_sol2_vec
     want64=true
     ;;
-  i[3-7]86-*-solaris2.[0-9]*)
+  i[3-7]86-*-solaris*)
     # PR 27666: Do not include i386_elf32_vec here.
     targ_defvec=i386_elf32_sol2_vec
     ;;
@@ -1341,10 +1341,6 @@ case "${targ}" in
     targ64_selvecs=sparc_elf64_sol2_vec
     want64=true
     ;;
-  sparc-*-solaris2.[0-6]*)
-    # PR 27666: Do not include sparc_elf32_vec here.
-    targ_defvec=sparc_elf32_sol2_vec
-    ;;
 #ifdef BFD64
   sparcv9-*-solaris2.[7-9]* | sparcv9-*-solaris2.1[01]* | \
   sparc64-*-solaris2.[7-9]* | sparc64-*-solaris2.1[01]*)
@@ -1376,6 +1372,10 @@ case "${targ}" in
     targ_defvec=sparc_elf32_vxworks_vec
     targ_selvecs="sparc_elf32_vec"
     ;;
+  sparc*-*-solaris*)
+    # PR 27666: Do not include sparc_elf32_vec here.
+    targ_defvec=sparc_elf32_sol2_vec
+    ;;
   sparc*-*-*)
     targ_defvec=sparc_elf32_vec
     ;;
diff --git a/ld/configure.tgt b/ld/configure.tgt
index 31fa2d8aded..abc94f8df39 100644
--- a/ld/configure.tgt
+++ b/ld/configure.tgt
@@ -378,7 +378,7 @@ i[3-7]86-*-solaris2.1[01]*)
 			targ_extra_emuls="elf_x86_64_sol2 elf_i386 elf_x86_64"
 			targ_extra_libpath=$targ_extra_emuls
 			;;
-i[3-7]86-*-solaris2.[0-9]*)
+i[3-7]86-*-solaris*)
 			targ_emul=elf_i386_sol2
 			targ_extra_emuls=elf_i386
 			targ_extra_libpath=$targ_extra_emuls
@@ -938,7 +938,7 @@ sparc-*-solaris2.[7-9]* | sparc-*-solaris2.1[01]*)
 			targ_extra_emuls="elf64_sparc_sol2 elf32_sparc elf64_sparc"
 			targ_extra_libpath=$targ_extra_emuls
 			;;
-sparc-*-solaris2.[0-6]*)
+sparc*-*-solaris*)
 			targ_emul=elf32_sparc_sol2
 			targ_extra_emuls=elf32_sparc
 			;;
diff --git a/ld/po/BLD-POTFILES.in b/ld/po/BLD-POTFILES.in
index 94bd7b0d2a8..d7d0c517307 100644
--- a/ld/po/BLD-POTFILES.in
+++ b/ld/po/BLD-POTFILES.in
@@ -204,7 +204,6 @@ eelf_i386.c
 eelf_i386_be.c
 eelf_i386_fbsd.c
 eelf_i386_haiku.c
-eelf_i386_ldso.c
 eelf_i386_sol2.c
 eelf_i386_vxworks.c
 eelf_iamcu.c
  

On 12.12.2025 15:51, Rainer Orth wrote:
>>> Regarding the solaris cleanup, I've been testing these two cross
>>> targets as part of my regression runs: "amd64-pc-solaris2.11" and
>>> "sparc-sun-solaris2".  The latter config slips past the obsolescence
>>> check in config.bfd and matches sparc*-*-*, and results in
>>> "Fatal error: selected target format 'elf32-sparc-sol2' unknown"
>>> from gas.
>>>
>>> Here's what I propose to tidy this.  I'll commit it on your OK.
>>
>> But weren't *-*-solaris2 supposed to continue to work, kind of as a
>> wildcard for *-*-solaris2.1* ? I'm, too, having
>> targets of that form in my set used for "global" testing.
> 
> I'd rather not do such silent under-the-hood aliasing if it can be
> avoided.  I'd rather match what GCC's gcc/config.gcc does instead:
> 
> # Unsupported targets list.  Do not put an entry in this list unless
> # it would otherwise be caught by a more permissive pattern.  The list
> # should be in alphabetical order.
> case ${target}${target_min} in
> [...]
>  | *-*-solaris2				\
>  | *-*-solaris2.[0-9]			\
>  | *-*-solaris2.[0-9].*			\
>  | *-*-solaris2.10*			\
>  | *-*-solaris2.11.[0-3]*		\
> [...]
> 	echo "*** Configuration ${target}${target_min} not supported" 1>&2
> 	exit 1

I really can see pros and cons. First - maybe simply using "solaris2" was
ambiguous in the past, so I shouldn't have used it. I didn't know better,
though. Otoh forcing people to use "solaris2.10" or "solaris2.11" is
overly specific imo: When having to pick a precise version, my expectation
would be that the result then isn't suitable for the respective other
target. Whereas my understanding is that from a binutils perspective 2.10
and 2.11 are identical. Hence minimally I wonder whether "solaris-2.1x"
should also be accepted, perhaps by way of using "solaris-2.1*" as glob
pattern. Unless of course there is 2.12 in existence as well, and not
compatible with 2.10 / 2.11.

Jan
  

On Mon, Dec 15, 2025 at 09:02:26AM +0100, Jan Beulich wrote:
> On 12.12.2025 15:51, Rainer Orth wrote:
> >>> Regarding the solaris cleanup, I've been testing these two cross
> >>> targets as part of my regression runs: "amd64-pc-solaris2.11" and
> >>> "sparc-sun-solaris2".  The latter config slips past the obsolescence
> >>> check in config.bfd and matches sparc*-*-*, and results in
> >>> "Fatal error: selected target format 'elf32-sparc-sol2' unknown"
> >>> from gas.
> >>>
> >>> Here's what I propose to tidy this.  I'll commit it on your OK.
> >>
> >> But weren't *-*-solaris2 supposed to continue to work, kind of as a
> >> wildcard for *-*-solaris2.1* ? I'm, too, having
> >> targets of that form in my set used for "global" testing.
> > 
> > I'd rather not do such silent under-the-hood aliasing if it can be
> > avoided.  I'd rather match what GCC's gcc/config.gcc does instead:
> > 
> > # Unsupported targets list.  Do not put an entry in this list unless
> > # it would otherwise be caught by a more permissive pattern.  The list
> > # should be in alphabetical order.
> > case ${target}${target_min} in
> > [...]
> >  | *-*-solaris2				\
> >  | *-*-solaris2.[0-9]			\
> >  | *-*-solaris2.[0-9].*			\
> >  | *-*-solaris2.10*			\
> >  | *-*-solaris2.11.[0-3]*		\
> > [...]
> > 	echo "*** Configuration ${target}${target_min} not supported" 1>&2
> > 	exit 1
> 
> I really can see pros and cons. First - maybe simply using "solaris2" was
> ambiguous in the past, so I shouldn't have used it. I didn't know better,
> though. Otoh forcing people to use "solaris2.10" or "solaris2.11" is
> overly specific imo: When having to pick a precise version, my expectation
> would be that the result then isn't suitable for the respective other
> target. Whereas my understanding is that from a binutils perspective 2.10
> and 2.11 are identical. Hence minimally I wonder whether "solaris-2.1x"
> should also be accepted, perhaps by way of using "solaris-2.1*" as glob
> pattern. Unless of course there is 2.12 in existence as well, and not
> compatible with 2.10 / 2.11.

Whether or not binutils should accept other than solaris2.10 or
solaris2.11 is a separate issue to the one I found with using
solaris2, so I'm going to respect Rainer's choice on that and commit
my fix for internal binutils consistency.