Closed James-E-A closed 1 year ago
On my Ubuntu 19.10 machine:
$ ls -l /usr/lib/x86_64-linux-gnu/libpcap.so*
lrwxrwxrwx 1 root root 14 Oct 8 13:37 /usr/lib/x86_64-linux-gnu/libpcap.so -> libpcap.so.0.8
lrwxrwxrwx 1 root root 16 Oct 8 13:37 /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 -> libpcap.so.1.9.1
-rw-r--r-- 1 root root 302424 Oct 8 13:37 /usr/lib/x86_64-linux-gnu/libpcap.so.1.9.1
What version does Fedora provide?
$ file /usr/lib64/libpcap.so* #OS-provided
/usr/lib64/libpcap.so.1: symbolic link to libpcap.so.1.9.1
/usr/lib64/libpcap.so.1.9.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=417358e56a3e12abff08c6bf8610418602756988, stripped
$ file /usr/local/lib64/libpcap.so* #stolen from Debian
/usr/local/lib64/libpcap.so.0.8: symbolic link to libpcap.so.1.9.1
/usr/local/lib64/libpcap.so.1.9.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=56f6cb080445575381f2f1dc988ea11a01cfb25c, stripped
$ ^C
$ #however, NOTE that, despite the apparently-matching version,
$ #the OS-provided library is not compatible (this error is reflected in run-attempts):
$ ^C
$ LD_LIBRARY_PATH=/usr/lib64 ldd `which nmrpflash` | grep libpcap
libpcap.so.0.8 => not found
$ LD_LIBRARY_PATH=/usr/local/lib64 ldd `which nmrpflash` | grep libpcap
libpcap.so.0.8 => /usr/local/lib64/libpcap.so.0.8 (0x00007fe786a0b000)
$
(as I judge it, it's entirely possible the "fault" per se lies squarely with Red Hat in this case)
Does nmrpflash
work with the library provided by RedHat? I.e. when running
# ln -s /usr/lib64/libpcap.so.1.9.1 /usr/lib64/libpcap.so.0.8
beforehand?
It would seem, strangely, that whatever functions nmrpflash
identifies as requiring from libpcap-0.8
are satisfiable by libpcap-1.9.1
[user@Fedora31 tmp]$ nmrpflash -V
nmrpflash: error while loading shared libraries: libpcap.so.0.8: cannot open shared object file: No such file or directory
[user@Fedora31 tmp]$ ldd `which nmrpflash` | grep libpcap
libpcap.so.0.8 => not found
[user@Fedora31 tmp]$ sudo ln -sv libpcap.so.1 /usr/lib64/libpcap.so.0.8
'/usr/lib64/libpcap.so.0.8' -> 'libpcap.so.1'
[user@Fedora31 tmp]$ ldd `which nmrpflash` | grep libpcap
libpcap.so.0.8 => /lib64/libpcap.so.0.8 (0x00007f21b2382000)
[user@Fedora31 tmp]$ nmrpflash -V
nmrpflash 0.9.14
[user@Fedora31 tmp]$
I'll reiterate the key/workaround for anyone skimming this thread:
# RPM-based distributions
sudo ln -sv libpcap.so.1 /usr/lib64/libpcap.so.0.8
# DEB-based distributions
sudo ln -sv libpcap.so.1 /usr/lib/`uname -m`-linux-gnu/libpcap.so.0.8
Though this workaround is unnecessary on recent Ubuntu versions as a compatibility symlink apparently already exists /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 -> libpcap.so.1.9.1
I'll consider forcing the linker to use libpcap.so.1
for the next build! I'll leave this open until then.
It's been almost two years now, but the fix isn't as easy as it first seemed. There is no .so
name that is common to both distros, as can be seen from my current Ubuntu 21.10 system:
$ ls -l /usr/lib/x86_64-linux-gnu/libpcap*
-rw-r--r-- 1 root root 512476 Okt 7 12:17 /usr/lib/x86_64-linux-gnu/libpcap.a
lrwxrwxrwx 1 root root 14 Okt 7 12:17 /usr/lib/x86_64-linux-gnu/libpcap.so -> libpcap.so.0.8
lrwxrwxrwx 1 root root 17 Okt 7 12:17 /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 -> libpcap.so.1.10.0
-rw-r--r-- 1 root root 310592 Okt 7 12:17 /usr/lib/x86_64-linux-gnu/libpcap.so.1.10.0
... and a Fedora 35 live CD:
$ ls -l /usr/lib64/libpcap*
lrwxrwxrwx. 1 root root 17 Jul 22 11:47 /usr/lib64/libpcap.so.1 -> libpcap.so.1.10.1
-rwxr-xr-x. 1 root root 314360 Jul 22 11:47 /usr/lib64/libpcap.so.1.10.1
So the easiest solution would be to link libpcap statically... I'll think about it.
My fedora version 36 and the same error occurs when I was trying to install wine5, solved shifting to wine6. libpcap.so.0.8 might be deprecated.
# RPM-based distributions sudo ln -sv libpcap.so.1 /usr/lib64/libpcap.so.0.8
This worked for me in Fedora 36
I'm thinking about releasing Linux builds as AppImages in the future. Can you verify that the file below runs as is on Fedora?
Never mind. I've tested it myself, and it works as expected! Finally closing this!
For reference and for anyone else running across this bug:
stealinglibpcap0.8_1.9.1-2_amd64.deb
from Debian and extracting everything fromdata.tar.xz/./usr/lib/x86_64-linux-gnu/
into somewhere inLD_LIBRARY_PATH
workedThe most efficient patch for this is
sudo ln -sv libpcap.so.1 /usr/lib64/libpcap.so.0.8
(Red Hat) orsudo ln -sv libpcap.so.1 /usr/lib/`uname -m`-linux-gnu/libpcap.so.0.8
(Debian), assuming/afterlibpcap
is already installed