[Guy Harris <gharris@xxxxxxxxxxxx>]

> I just installed ethereal 0.83 on a RedHat 6.1 installation, together with
> the UCD snmp package and the patched libpcap library.  When I try to run
> ethereal, I get the following message,
> 
> ethereal: error in loading shared libraries: ethereal: undefined symbol:
> snmp_set_full_objid             
> 
> Could some one clue me in as to what I'm missing ?

Shared libraries built by folks who understood what the version number
in the name of a shared library is for. :-(

It appears that, between the 4.0[.x] and 4.1[.x] versions of the UCD
SNMP library, the folks at UCD made a change that broke binary
compatibility.  Not a problem - unless you're dealing with shared
libraries....

In the 4.0[.x] library, "snmp_set_full_objid()" is a subroutine.

In the 4.1[.x] library, it's a *macro* that turns into a call to
"ds_set_boolean()".

This means that any program built with a shared-library version of UCD
SNMP 4.0[.x] and that calls "snmp_set_full_objid()" - Ethereal calls
that routine - will fail to work with a shared-library version of UCD
SNMP 4.1[.x].

Even more unfortunately, it appears (from other mail you sent) that
whoever build the UCD SNMP 4.1.1 RPMs gave the shared library a version
number of 0 (i.e., it's name is "libsnmp.so.0"), which is probably the
same version number that the shared libraries in the 4.0[.x] RPMs have.

The shared library mechanism in the free UNIXes (Linux,
{Free,Net,Open}BSD) is largely a clone of the one from System V Release
4 (not surprising, given that the object/executable image/shared
library/core dump format of those free UNIXes is SVR4's format, namely
ELF), which is, in turn, based on the one from SunOS 4.x.

The 4.x mechanism gave shared libraries a "major" and "minor" version
number; when a program is compiled and linked, the version numbers of
all shared libraries with which it links is recorded in the program's
executable image.  The run-time linker will link it only with shared
libraries with the same major version number; if it can't find such a
library, it'll refuse to run the program.  If it finds a library with
the same major version number as the one of the version of that library
with which the program was built, but a minor version number lower than
the one for that version of the library, it'll print a warning, but
continue to run; if it finds one with a minor version number greater
than or equal to that version, it'll run with no warning.

The intent was that if a library changed in such a fashion that programs
linked with the new version might not work with an older version (for
example, if a new routine was added to the library), the minor version
number should be increased, and if it changed in such a fashion that
programs linked with an older version might not work with the new
version, the major version number should be increased.  That way,
compatibility problems such as this will be caught and reported as such.

The SVR4 mechanism, alas, got rid of the minor version numbers - but the
major version numbers are still there.

As such, the RPMs for the 4.1[.x] versions should've been given a
greater major version number, i.e. have been "libsnmp.so.1". 

Unfortunately, what's done is done, so you'll have to build Ethereal
from source (as will anybody else who's on a platform on which

	1) there are binary distributions of pre-4.1[.x] UCD SNMP and
	   4.1[.x] UCD SNMP that have the same shared library version
	   number;

	2) Ethereal binary packages are available, linked with
	   pre-4.1[.x] UCD SNMP shared libraries

such as Red Hat Linux).

I'll put a note about this in the README file.  Those building binary
packages for those platforms might want to provide both versions for
sites with pre-4.1[.x] UCD SNMP (linked with a pre-4.1[.x] UCD SNMP
shared library) and sites with 4.1[.x] (linked with a 4.1.1 shared
library).