On Sat, Jul 10, 2004 at 01:43:10AM -0700, Guy Harris wrote:
> On Sat, Jul 10, 2004 at 10:36:33AM +0200, Gisle Vanem wrote:
> > >From it's FAQ: "for host resources mib support".
>
> Which says:
>
> Note that this will only affect you if you are trying to compile in
> the host resources mib support, as it'll try to use the rpm libraries
> which will in turn require that libelf.a or libelf.so be present.
net-snmp 5.1.1 uses libelf for ``nlist'' on some platforms, GNU/Linux _not_
among them. As such, compiling from source in the absence of elfutils-devel
works, but since Net-SNMP does not decide whether to use nlist until build time,
it always links with libelf is that library is available at configure time. If
elfutils-devel was present at package build time (as is the case in the official
RPM build environment), every client of net-snmp encounters this linking problem
whenever elfutils-devel is absent for the build of that client program.
Redhat should make net-snmp-devel depend on elfutils-devel. Problem solved.
If net-snmp wanted to avoid this problem, it could calculate whether to use
nlist at configure time rather than build time and only try to include -lelf if
it will actually use nlist.
> which raises the question "so why does it use the rpm libraries for
> support for the host resources MIB?", and the futher question "what are
> the rpm libraries" - I'm not sure why an SNMP library would need
> libraries for dealing with RPMs at all, much less requiring them to get
> parameters such as system uptime, but maybe the rpm libraries are
> something other than libraries to access RPMs.
>
> (I.e., why would an SNMP library need to know either about object file
> formats or software binary package formats?)
That text probably intended to communicate that Net-SNMP tries to use the
(libelf) libraries installed via RPMs. Net-SNMP does not use libraries that
provide interfaces for manipulating RPM packages. Rather, on some systems it
uses nlist from libelf to read information such as uptime from /dev/kmem.
