nmrpflash icon indicating copy to clipboard operation
nmrpflash copied to clipboard

libpcap.so.0.8 not widely available (e.g., Fedora 31)

Open James-E-A opened this issue 5 years ago • 8 comments

For reference and for anyone else running across this bug:

~~stealing libpcap0.8_1.9.1-2_amd64.deb from Debian and extracting everything from data.tar.xz/./usr/lib/x86_64-linux-gnu/ into somewhere in LD_LIBRARY_PATH worked~~

The most efficient patch for this is sudo ln -sv libpcap.so.1 /usr/lib64/libpcap.so.0.8 (Red Hat) or sudo ln -sv libpcap.so.1 /usr/lib/`uname -m`-linux-gnu/libpcap.so.0.8 (Debian), assuming/after libpcap is already installed

James-E-A avatar Mar 08 '20 03:03 James-E-A

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?

jclehner avatar Mar 08 '20 12:03 jclehner

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

James-E-A avatar Mar 13 '20 20:03 James-E-A

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?

jclehner avatar Mar 14 '20 00:03 jclehner

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

James-E-A avatar Mar 23 '20 04:03 James-E-A

I'll consider forcing the linker to use libpcap.so.1 for the next build! I'll leave this open until then.

jclehner avatar May 11 '20 14:05 jclehner

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.

jclehner avatar Jan 02 '22 11:01 jclehner

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.

Qervas avatar Jun 15 '22 06:06 Qervas

# RPM-based distributions
sudo ln -sv libpcap.so.1 /usr/lib64/libpcap.so.0.8

This worked for me in Fedora 36

adi-zigio avatar Aug 03 '22 09:08 adi-zigio

I'm thinking about releasing Linux builds as AppImages in the future. Can you verify that the file below runs as is on Fedora?

nmrpflash-0.9.20-19-g382346c-linux-x86_64.tar.gz

jclehner avatar Sep 09 '23 13:09 jclehner

Never mind. I've tested it myself, and it works as expected! Finally closing this!

jclehner avatar Sep 15 '23 09:09 jclehner