Ethereal-users: Re: [ethereal-users] Re: Any clues: undefined symbol: snmp_set_suffix_only
On Tue, Aug 15, 2000 at 05:02:10PM +0900, sen_ml@xxxxxxxxxxx wrote:
> i don't use rh, but it seems like you might be missing some
> snmp-related libraries (or they're not in a place that the dynamic
> linking mechanisms are looking).
No, he has the libraries, but the RH 6.2 UCD SNMP library isn't
binary-compatible with the RH 6.1 UCD SNMP library, and the RPMs for
Ethereal are apparently built on 6.1 or earlier; see my reply to his
message, which includes the latest shiniest version of Ethereal FAQ 3.5
"3.5: Ethereal will not run because snmp_set_full_objid or
snmp_set_suffix_only is an undefined symbol." (Yes, I know, that's not
a question, it's a statement....)
There's a workaround in 0.8.10, but the workaround operates by
"dlopen()"ing "libsnmp.so" and poking it to see what's inside;
unfortunately, that only works if "libsnmp.so" refers to the installed
UCD SNMP library, but that's the case only if there's a link
"libsnmp.so" to "libsnmp.so.0".
If anybody has any bright ideas about how to determine, at run time in
an application, the pathname of the UCD SNMP library that the
application has loaded *without* calling "dladdr()" (unless RH 6.x has
"dladdr()" for all values of "x", in which case we could throw into the
configure script a check for "dladdr()"), speak up - I'm loath to just
duplicate all the code in the Linux run-time linker, as that
1) probably requires Ethereal to read the run-time linker control
files, making Ethereal dependent on the format of a binary
file that may change from OS release to OS release
and
2) probably requires Ethereal to match the run-time linker's
behavior in other ways, making it dependent on the behavior
of an OS module that may change from OS release to OS
release.
