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

Apologies for the delay, will resolve it this week.

Thanks,
Sumit

On Sun, 21 Dec 2025 at 8:15 AM, Jessica Clarke <jrtc27@freebsd.org> wrote:

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