[PATCH v1 1/1] bfd: add a mean to programatically detect a release version

[Matthieu Longo]

On 2025-08-27 08:27, Jan Beulich wrote:
> On 26.08.2025 19:48, Matthieu Longo wrote:
>> On 2025-08-21 17:00, Jan Beulich wrote:
>>> On 14.08.2025 17:16, Matthieu Longo wrote:
>>>> In a recent discussion around Object Attributes v2, it appeared that we
>>>> needed a way to detect whether a tool was built as a release version,
>>>> or development version.
>>>>
>>>> A previous patch (7b40f4c6587c) introduced this detection in gas.
>>>> This patch reuses the same principle but moved the code into a utility
>>>> function in bsd, so that gas, ld, and others can rely on it. It also
>>>> adds a Tcl function 'is_release' that can be used with a '#target: '
>>>> directive to disable some tests relying on development-only features.
>>>
>>> The C side is pretty much okay with me, but ...
>>>
>>>> --- a/binutils/testsuite/lib/binutils-common.exp
>>>> +++ b/binutils/testsuite/lib/binutils-common.exp
>>>> @@ -17,6 +17,19 @@
>>>>    # Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
>>>>    # MA 02110-1301, USA.
>>>>    
>>>> +# True if the current tool is a release version.
>>>> +#
>>>> +proc is_release {} {
>>>> +  global AS
>>>> +  catch "exec $AS --version | head -1" exec_output
>>>
>>> ... already here implementation and comment ("current tool") don't match.
>>> For some targets gas isn't even being built. If you only need this for
>>> gas, maybe limit it to just that?
>>>
>>
>> This test is used in both ld and gas tests. The code that has a
>> different behavior at runtime is located in bfd, and is used by both gas
>> and ld.
>>
>> If ld is built for all targets, I can replace $AS by $LD. Or might ld
>> not be present in some cases ?
> 
> Indeed, ld would similarly not be built for some targets. Whether among
> those would be any ELF ones which at the same time do build gas I don't
> know. One ELF one I'm aware of not building ld, but building gas is
> aarch64-netbsd. The ones I'm aware of not building gas would also not
> build ld. The top-level configure script's setting of noconfigdirs may
> give you some hints, but sadly I have found the sets there to be
> incomplete (I have a local patch to correct those few cases that get in
> the way of my testing, but I don't dare to post such a patch).
> 
> [Note: "not building" is meant to also cover the case of "failing to
> build", i.e. cases where something's likely missing from noconfigdirs.]
> 

I am still confused about this configuration where AS would not be built 
but LD would, or vice versa. How can the LD tests be run if the version 
of AS is not aligned with LD ? Those two should go hand in hand, 
otherwise the tests might rely on unimplemented features in AS.

>>>> +  if [regexp {\d+\.\d+\.\d+(\.\d+)} $exec_output matched sub1] then {
>>>
>>> I have no idea whether this may get in conflict with some distro's versioning.
>>
>> How could the pattern be changed to remove this risk ? Since I don't
>> have BFD_VERSION_DATE like in bfd_is_release_version(), I don't see
>> anything obvious. Any suggestion ?
> 
> Sadly I have no suggestion. I was merely raising a concern.
> >> FYI, in the specific case I would like to use it (see your comment on
>> OAv2 patch series), if the distribution were to use a conflicting
>> version scheme, it would at worst cause some tests to be executed
>> whereas they should be skipped, and thus they would appear as test
>> failures. Do the distributions execute the binutils tests every time
>> they generate a new artifact ?
> 
> I don't know.
> 
> Jan