Re: git: 35dd53a9e132 - main - librdmacm/libibverbs: Statically bound libbnxtre.so.1 to rping

From: Jessica Clarke <jrtc27_at_freebsd.org>
Date: Sun, 21 Dec 2025 02:45:12 UTC
On 3 Dec 2025, at 14:13, Jessica Clarke <jrtc27@FreeBSD.org> wrote:
> 
> On 3 Dec 2025, at 11:34, Sumit Saxena <ssaxena@freebsd.org> wrote:
>> 
>> The branch main has been updated by ssaxena:
>> 
>> URL: https://cgit.FreeBSD.org/src/commit/?id=35dd53a9e13265f7a479649776453efc5b737a0f
>> 
>> commit 35dd53a9e13265f7a479649776453efc5b737a0f
>> Author:     Sumit Saxena <ssaxena@FreeBSD.org>
>> AuthorDate: 2025-12-03 11:28:33 +0000
>> Commit:     Sumit Saxena <ssaxena@FreeBSD.org>
>> CommitDate: 2025-12-03 11:33:40 +0000
>> 
>>   librdmacm/libibverbs: Statically bound libbnxtre.so.1 to rping
>> 
>>   By default ibv_devices and rping are not statically bound to
>>   libbnxtre.so.1. i.e. 'ldd /usr/bin/rping' command doesn't list
>>   'libbnxtre.so.1' entry. So, statically bound the libbnxtre.so.1
>>   library to rping & ibv_devices utils.
> 
> Firstly, this is some very unusual terminology, there’s no “binding”
> going on here (binding in ELF linker/loader terminology is about
> symbols, not libraries), it’s “linking”. Also, whilst strictly true
> that this pertains to the static linker, repeating the static part
> makes it sound like you’re talking about static linking in the ld
> -static / libfoo.a sense, which would still have the effect of not
> showing up in ldd’s output.
> 
> Secondly, this states some things, but I don’t see why this change
> follows from it. *Why* does it matter that ibv_devices and rping do not
> link against libbnxtre? If it builds, that means none of libbnxtre’s
> symbols were needed. Is there some magic dynamic registration going on
> in linker sets / constructors inside libbnxtre? Please explain the why
> in the commit message.

Ping? I don’t see any follow-up to this.

Jessica