Should there be a link from libpcap.so to the latest version of the libpcap.so.xxx library?

if you need libraries with numbers on the end, you can make symlinks to effectively humour the app. this is fairly commonplace.

is this what you mean?

Actually the opposite. I thought it was common place if there was libpcap.so.1.1.1 that there would be a symlink of libpcap.so that would point at the actual library. I'm not seeing this though even though it is done for many other libraries. Id like the libpcap.so symlink so my program wouldn't have to know the specific version of the library.

Chris

andy@fileserver:/usr/lib$ file /usr/lib/i386-linux-gnu/libpcap.so.0.8
/usr/lib/i386-linux-gnu/libpcap.so.0.8: symbolic link to `libpcap.so.1.1.1'

andy@fileserver:/usr/lib$ file /usr/lib/i386-linux-gnu/libpcap.so.1.1.1
/usr/lib/i386-linux-gnu/libpcap.so.1.1.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

Here, an app expects libpcap.so.0.8 but I have libpcap.so.1.1.1, there is a symlink to the later version which will make the app work, personally I think there should be one libpcap and all files just use that (as long as it is at a recent enough version (managed by apt))

Should I expect that there is a libpcap.so.0.8 on several recent releases of ubuntu, fedora, suse etc?

I'm ok with changing my mapping from libpcap.so to libpcap.so.0.8 but its for a library that users may use on many different distributions. That's why I was asking if there should be a symlink from libpcap.so -> libpcap.so.1.1.1

Chris

cmorgan, did you install the -dev package? The symlink is usually only installed with the development data (eg headers).

THis package lists the .so (although it is in the multiarch dir).
http://packages.ubuntu.com/oneiric/i386/libpcap0.8-dev/filelist

So should I be using libpcap.so.0.8 in my dll mapping? Is that the file most likely to be present on modern distributions if libpcap is installed?

>So should I be using libpcap.so.0.8 in my dll mapping
It depends on your intentions with the program you are working on, and how you intend to release it. If the libpcap maintainers decide to release a new version of their library, then it may go to libpcap.so.0.9, or libpcap.so.0.9.1.

If the program is only run on your own systems, then by all means, just map to the version of libpcap on your system. Otherwise in general, the most *optimum* solution is that you should be either:

1) releasing the source code, so others "Maintainers" can construct build scripts that integrate with the appropriate libraries (usually version changes mean very little needs to be done - often an automatic recompilation is all) - this is the method by which the debian archive is built ( Ubuntu imports and builds the debian archive + some custom modifications)

2) Setting up an in-house build-system that has VMs with each platform you intend to target, that automatically installs updates and re-tests/builds your program if needed. This needs to include tests, as some ABI changes won't be automatically detected with the dll mapping.

If you can't do this, then you need to restrict yourself to targeting specific linux distributions and release data. You can build custom binary installer-debs that only target particular version of a particular distribution that you know works.

Usually distributions will not break their current binary compatibility during a single version, but you should *never* assume that a binary built on linux distribution A is compatible with another distribution B. Eg assuming that what works on ubuntu will work on debian is a no-no.

After some more investigation it looks like ubuntu/debian may be the exception.

Fedora ships libpcap.so.1.2.1 and a symlink to libpcap.so.1. OpenSuse 10.5 libpcap.so.0.9.7 and a symlink to libpcap.so.0.

If ubuntu had a symlink from libpcap.so.1.1.1 to libpcap.so.1 I think that would address the issue in a standard way that seems to make sense.

I suggest you report a bug

Tried to use the 'link existing bug' feature but it reported a cifs mount error.

Bug reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657900

Oh doh. I plugged the debian bug number into the link existing bug thing. Didn't realize they weren't unique numbers. doh.