[PATCH] Cleanup bfd target vectors and ld emulations on Solaris

Jan Beulich jbeulich@suse.com
Mon Dec 15 08:02:26 GMT 2025


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


More information about the Binutils mailing list