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

Jan Beulich jbeulich@suse.com
Wed Aug 27 07:27:58 GMT 2025


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.]

>>> +  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


More information about the Binutils mailing list