Right now building libpcap will automagically link against libibverbs if it is present. See https://github.com/the-tcpdump-group/libpcap/blob/d396f255cf7b96a09cf91d0e8cc94d23777d6986/configure.ac#L2397 I caught this with my own early build of rdma-core (having it installed when building libpcap and then removing it): >>> package: sys-fabric/rdma-core-17.1 * - /usr/lib64/libibverbs.so.1 * - /usr/lib64/libibverbs.so.1.1.17.1 * used by /usr/lib64/libpcap.so.1.9.1 (net-libs/libpcap-1.9.1) Reproducible: Always
(In reply to Daniel M. Weeks from comment #0) > Right now building libpcap will automagically link against libibverbs if it > is present. See > https://github.com/the-tcpdump-group/libpcap/blob/ > d396f255cf7b96a09cf91d0e8cc94d23777d6986/configure.ac#L2397 > > I caught this with my own early build of rdma-core (having it installed when > building libpcap and then removing it): > >>> package: sys-fabric/rdma-core-17.1 > * - /usr/lib64/libibverbs.so.1 > * - /usr/lib64/libibverbs.so.1.1.17.1 > * used by /usr/lib64/libpcap.so.1.9.1 (net-libs/libpcap-1.9.1) > > Reproducible: Always I am not sure where this is going. There is no package in the tree providing a libibverbs right now: checking whether libibverbs defines ibv_create_flow... no because apparently that is not what (ancient?) sys-fabric/libibverbs provides. In detail: configure:11654: checking for ibv_get_device_list in -libverbs configure:11679: x86_64-pc-linux-gnu-gcc -o conftest -frecord-gcc-switches -g -pipe -O2 -Wall -march=amdfam10 -mtune=amdfam10 -Wno-comment -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -libverbs -lnl-genl-3 -lnl-3 -lssl -lcrypto -ldbus-1 >&5 configure:11679: $? = 0 configure:11688: result: yes configure:11692: checking infiniband/verbs.h usability configure:11692: x86_64-pc-linux-gnu-gcc -c -frecord-gcc-switches -g -pipe -O2 -Wall -march=amdfam10 -mtune=amdfam10 -Wno-comment conftest.c >&5 configure:11692: $? = 0 configure:11692: result: yes configure:11692: checking infiniband/verbs.h presence configure:11692: x86_64-pc-linux-gnu-gcc -E conftest.c configure:11692: $? = 0 configure:11692: result: yes configure:11692: checking for infiniband/verbs.h configure:11692: result: yes configure:11706: checking whether libibverbs defines ibv_create_flow configure:11724: x86_64-pc-linux-gnu-gcc -o conftest -frecord-gcc-switches -g -pipe -O2 -Wall -march=amdfam10 -mtune=amdfam10 -Wno-comment -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -lnl-genl-3 -lnl-3 -lssl -lcrypto -ldbus-1 >&5 conftest.c: In function 'main': conftest.c:73:13: warning: implicit declaration of function 'ibv_create_flow'; did you mean 'ibv_create_ah'? [-Wimplicit-function-declaration] 73 | (void) ibv_create_flow((struct ibv_qp *) NULL, | ^~~~~~~~~~~~~~~ | ibv_create_ah /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /home/jer/portage/net-libs/libpcap-9999/temp/ccoiCWAM.o: in function `main': /home/jer/portage/net-libs/libpcap-9999/work/libpcap-9999-abi_x86_64.amd64/conftest.c:73: undefined reference to `ibv_create_flow' collect2: error: ld returned 1 exit status But now you say you have some local (or just not widely available?) ebuild that provides libibverbs and that the libpcap ebuilds in the tree should now care for?
(In reply to Daniel M. Weeks from comment #0) > >>> package: sys-fabric/rdma-core-17.1 You are aware of sys-cluster/rdma-core?
(In reply to Jeroen Roovers from comment #2) > (In reply to Daniel M. Weeks from comment #0) > > >>> package: sys-fabric/rdma-core-17.1 > > You are aware of sys-cluster/rdma-core? Yes, as I said, this was caught when I removed an older, local version of rdma-core to replace it with the in-tree ebuild. Once I emerged the in-tree ebuild for rdma-core the link was satisfied again: ldd /usr/lib64/libpcap.so.1.9.1 linux-vdso.so.1 (0x00007ffe9b961000) libibverbs.so.1 => /usr/lib64/libibverbs.so.1 (0x00007fe488dc5000) libc.so.6 => /lib64/libc.so.6 (0x00007fe488bf6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe488bd3000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fe488bcd000) /lib64/ld-linux-x86-64.so.2 (0x00007fe488e78000) > There is no package in the tree providing a libibverbs right now rdma-core libpcap configure with rdma-core installed: checking for ibv_get_device_list in -libverbs... yes checking infiniband/verbs.h usability... yes checking infiniband/verbs.h presence... yes checking for infiniband/verbs.h... yes checking whether libibverbs defines ibv_create_flow... yes
Keyword sys-cluster/rdma-core or mask USE=rdma for net-libs/libpcap, then keyword =net-libs/libpcap-1.9.1-r3
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3dec6a80f9c8c540966b77d731c91b7e40f2e6ca commit 3dec6a80f9c8c540966b77d731c91b7e40f2e6ca Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-01-19 20:41:05 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-01-19 20:47:38 +0000 net-libs/libpcap: Disable RDMA support. Package-Manager: Portage-2.3.84, Repoman-2.3.20 Bug: https://bugs.gentoo.org/705802 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-libs/libpcap/libpcap-1.9.1-r2.ebuild | 1 + net-libs/libpcap/libpcap-1.9.1.ebuild | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-)
An automated check of this bug failed - the following atom is unknown: sys-cluster/rdma-core Please verify the atom list.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab5dc584e32e10865aeaace994b754e0baf6d888 commit ab5dc584e32e10865aeaace994b754e0baf6d888 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-01-20 13:29:47 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-01-20 13:30:44 +0000 net-libs/libpcap: Mark ~hppa Package-Manager: Portage-2.3.84, Repoman-2.3.20 Bug: https://bugs.gentoo.org/show_bug.cgi?id=705802 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-libs/libpcap/libpcap-1.9.1-r3.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f3e089533621ac9e42bded579af6b0718429dd5b commit f3e089533621ac9e42bded579af6b0718429dd5b Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-01-20 13:24:11 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-01-20 13:30:42 +0000 sys-cluster/rdma-core: Mark ~hppa Package-Manager: Portage-2.3.84, Repoman-2.3.20 Bug: https://bugs.gentoo.org/show_bug.cgi?id=705802 Signed-off-by: Jeroen Roovers <jer@gentoo.org> sys-cluster/rdma-core/rdma-core-27.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=515be3887dff8be8abc90914293f0d8fdac591a9 commit 515be3887dff8be8abc90914293f0d8fdac591a9 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-01-20 13:36:35 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-01-20 13:36:51 +0000 sys-cluster/rdma-core: Mark ~hppa Package-Manager: Portage-2.3.84, Repoman-2.3.20 Bug: https://bugs.gentoo.org/705802 Signed-off-by: Jeroen Roovers <jer@gentoo.org> sys-cluster/rdma-core/rdma-core-9999.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Jeroen Roovers from comment #4) > Keyword sys-cluster/rdma-core or mask USE=rdma for net-libs/libpcap, then > keyword =net-libs/libpcap-1.9.1-r3 Commit 131b508cae2558590a303e50c7f1cf088c93a8c6 does this for riscv. Removing the alias from the CC.
~ic64/~ppc/~ppc64 keyworded
~sparc keyworded
(In reply to Rolf Eike Beer from comment #12) > ~sparc keyworded atom updated :)
~sparc again
added ~alpha
SuperH port disbanded.
~arm64 added
~arm added
Unable to check for sanity: > no match for package: sys-cluster/rdma-core-28.0
All sanity-check issues have been resolved
~s390 added
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8e31df55cc42155a1ec3c86b017c128924e4f311 commit 8e31df55cc42155a1ec3c86b017c128924e4f311 Author: Matoro Mahri <matoro@users.noreply.github.com> AuthorDate: 2022-10-02 00:33:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-08 17:09:16 +0000 net-libs/libpcap: add test There's not really a test suite upstream (see mentioned link). There's a handful of "test programs" (which we at least test building and linking with this change), but this one (findalldevstest) is the only one that is actually run (under valgrind) in upstream CI. On the upside, it should be rather reproducible since only the loopback interface will ever be exposed inside the portage network sandbox. See: https://github.com/the-tcpdump-group/libpcap/issues/1012 Bug: https://bugs.gentoo.org/705802 Signed-off-by: Matoro Mahri <matoro@users.noreply.github.com> Closes: https://github.com/gentoo/gentoo/pull/27568 Signed-off-by: Sam James <sam@gentoo.org> net-libs/libpcap/libpcap-1.10.1-r2.ebuild | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
mips done all arches done
