Policy for removing target support

[Jan Beulich]

On 15.09.2025 13:28, Rainer Orth wrote:
> Hi Jan, Nick,

Properly handing to Nick, by putting him in To:. I had voiced view,
after all.

Jan

>>>>> I understand that; what I don't understand is which of the entries this
>>>>> covers. We don't have anything named e.g. "solaris9" in binutils.
>>>>
>>>> that's because config.guess has kept the Solaris 2.x nomenclature even
>>>> after Sun changed the naming from Solaris 2.7 to Solaris 7 immediately
>>>> before the release.  The Solaris name was used for the OS as a whole,
>>>> while the core OS is still called SunOS 5.7.  Since the configure triple
>>>> is derived from uname -s (SunOS) and -r (5.7), you still arrive at
>>>> *-*-solaris2.7.  Much of this is handled by wildcards in config.bfd and
>>>> configure.ld so not immediately visible in those scripts.  My overview
>>>> of new cases upthread intends to make this more explicit.
>>>
>>> Right, just that you didn't map the versions to our numbering scheme,
>>> thus leaving things unclear to anyone not familiar with the odd mapping
>>> that you describe above.
>>
>> I see: I'd assumed this was relatively common knowledge since it has
>> been this way for a decade and a half.
>>
>>>> I know this can be confusing, but that's the way things are.
>>>>
>>>> If the obsoletion/removal would go through, everything except
>>>> *-*-solaris2.1[01]* would go and *-*-solaris2.[0-9]* be rejected
>>>> in config.bfd.
>>>
>>> That's what I was fearing. People (like me) may have got used to simply
>>> saying "solaris2" in target specifiers. Sure, I (and others) can adjust
>>> their scripts and habits, but would that be for any gain? IOW would any
>>> actual code simplification result afterwards? Or in yet different words,
>>> have I perhaps failed to properly test the Solaris ports by saying just
>>> "2"?
>>
>> In general, solaris2* is ok in all but config.bfd and configure.tgt.  I
>> doubt we have many cases where things differ, so you should be fine
>> without change.
>>
>> The primary benefit of obsoletion/removal would be to make the supported
>> versions explicit.  As I said, I haven't yet checked in detail if/which
>> parts of code with anything < Solaris 10 removed from the test matrix
>> could go.
> 
> how should we proceed here then?  I see three options:
> 
> * Remove support for Solaris < 10 immediately.
> 
>   Given that all affected targets are long dead, support for them in
>   GCC has been removed between 10 and 12 years ago and they don't even
>   build since binutils 2.41, there's little point claiming support if it
>   doesn't actually work and nobody noticed.
> 
> * Alternatively, one could obsolete them instead and remove support at a
>   later point (when?).  That has the disadvantage of leaving the support
>   in bfd/config.bfd and ld/configure.tgt more complex than necessary and
>   sort of advertising support for OS versions that don't actually work.
> 
> * Do nothing.
> 
> For comparison's sake, the GCC policy for removal is simple: the target
> has still to be in active use *and* there needs to be someone who
> regularly tests it, reports and fixes bugs.  That wont certainly be me:
> I didn't remove the GCC support only to keep testing prehistoric OS
> versions in Binutils.
> 
> 	Rainer
>