FS#49204 - [iputils] missing dependency on nettle

Attached to Project: Arch Linux
Opened by Steven Noonan (neunon) - Wednesday, 04 May 2016, 10:39 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 16 November 2016, 08:01 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

iputils appears to directly depend on libnettle.so.6:

# ldd /usr/bin/ping
linux-vdso.so.1 (0x00007ffc9f1b3000)
libcap.so.2 => /usr/lib/libcap.so.2 (0x00007fd981215000)
libidn.so.11 => /usr/lib/libidn.so.11 (0x00007fd980fe1000)
libnettle.so.6 => not found
libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007fd980dca000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fd980a28000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd981419000)
# strings /usr/bin/ping | grep nettl
libnettle.so.6
nettle_md5_update
nettle_md5_digest
nettle_md5_init

But it's not a dependency of the iputils package:

# pacman -Qi iputils | grep Depends
Depends On : openssl sysfsutils libcap


It appears, based on the dependency on OpenSSL, that the intent of the PKGBUILD was that it would be using OpenSSL rather than nettle. To fix this, I'd suggest doing this:

$ git diff
diff --git a/iputils/trunk/PKGBUILD b/iputils/trunk/PKGBUILD
index ec31cdc..6474dd4 100644
--- a/iputils/trunk/PKGBUILD
+++ b/iputils/trunk/PKGBUILD
@@ -28,7 +28,7 @@ sha1sums=('SKIP'
build() {
cd "${srcdir}/${pkgname}"

- make USE_GNUTLS=no CCOPTOPT="$CFLAGS"
+ make USE_NETTLE=no USE_GNUTLS=no CCOPTOPT="$CFLAGS"

cd doc
for file in *.sgml; do


The above patch results in a 'ping' binary that depends on libcrypto instead:

$ ldd /usr/bin/ping
linux-vdso.so.1 (0x00007ffca4d9f000)
libcap.so.2 => /usr/lib/libcap.so.2 (0x00007fdcc8268000)
libidn.so.11 => /usr/lib/libidn.so.11 (0x00007fdcc8034000)
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fdcc7bbd000)
libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007fdcc79a5000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fdcc7603000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fdcc73ff000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x0000559482176000)
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Wednesday, 16 November 2016, 08:01 GMT
Reason for closing:  Fixed
Additional comments about closing:  20161105.1f2bb12-1
Comment by Doug Newgard (Scimmia) - Wednesday, 04 May 2016, 13:50 GMT
Please don't use ldd for things like this. It's recursive, so it will give you false positives. In this case, you're right, though.

Looks like libidn dep is also missing.
Comment by Steven Noonan (neunon) - Sunday, 08 May 2016, 14:38 GMT
I used ldd + strings, as I was aware of the recursive bit.. What would you prefer for this kind of thing in the future? "readelf -d <bin> | grep Shared" or something? Little bit less readable, but it works:

$ readelf -d /usr/bin/ping | grep Shared
0x0000000000000001 (NEEDED) Shared library: [libcap.so.2]
0x0000000000000001 (NEEDED) Shared library: [libidn.so.11]
0x0000000000000001 (NEEDED) Shared library: [libnettle.so.6]
0x0000000000000001 (NEEDED) Shared library: [libresolv.so.2]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Comment by Doug Newgard (Scimmia) - Sunday, 08 May 2016, 15:40 GMT
both readelf and objdump would be reliable ways of checking linking. Namcap can also give you the information if it's about missing deps, but not wrong versions.

Loading...