Ethereal-dev: Re: [ethereal-dev] Patch to "acinclude.m4" to fix UCD SNMP problem - please test
(Sent accidentally to "ethereal-cvs"; retransmitted as a reply to my
message to "ethereal-dev".)
> When I get home, I'll see if I can reconstruct the problem,
The problem is that the configure script was rather fragile. It didn't
forcibly insert "-I/usr/local/include" into the C compiler and C
preprocessor flags, and didn't forcibly insert "-R/usr/local/lib" into
the linker flags, so whether it found header files such as the SNMP
header files was dependent on whether
1) those files lived in "/usr/local/include" or in either a
system directory or in a directory explicitly specified with
"--with-ucdsnmp=";
2) "libpcap"s header file was in "/usr/local/include" or in a
system directory;
as, if the SNMP header files were in "/usr/local/include" (and that
wasn't specified with "--with-ucdsnmp="), and the "libpcap" header files
were in a system directory (e.g, "/usr/include"), then
1) as the "libpcap" header files were in a system directory,
"configure" didn't, at the time it was checking for
"libpcap", see any need to have the Makefile put
"-I/usr/local/include" in the compile commands, and thus
didn't add it to "CFLAGS" (or "CPPFLAGS")
and
2) as no other part of the configure file saw such a need by the
time it got around to checking for the SNMP header files, it
didn't bother looking there for the header files.
However, it apparently *did* have "/usr/local/lib" in its search path
for libraries (probably because that's where it found GTK+; that also
probably added "-I/usr/local/include" to "CFLAGS", but did *NOT* add it
to "CPPFLAGS", the latter, not the former, being what is used when
searching for header files), so it *did* find "asn_parse_header" in
"-lsnmp".
As such, it said that it should include "packet-snmp.c" in the build,
but defined neither HAVE_SNMP_SNMP_H nor HAVE_UCD_SNMP_SNMP_H, so
"packet-snmp.c" compiled into nothing.
However, it *was* scanned for "proto_register_snmp()", so a call to it
was added to "register.c", even though that routine didn't get compiled
in.
That problem was fixed by arranging that "proto_register_snmp()"
*always* be compiled into "packet-snmp.o", even if neither
HAVE_SNMP_SNMP_H nor HAVE_UCD_SNMP_SNMP_H was defined (it compiled into
a no-op routine, registering nothing, if neither of those were defined).
However, that *still* meant that, at least on my FreeBSD machine, I
didn't get SNMP dissection support in Ethereal even though I'd installed
the UCD SNMP library.
So I changed "configure.in" to forcibly add "-I/usr/local/include" to
"CFLAGS" and "CPPFLAGS", and add "-L/usr/local/include" to "LIBS", on
the grounds that
1) there's a decent chance that Ethereal will need some library
package from "/usr/local"
and
2) it might not break anything if we did that.
That seemed to fix the problem.
(I also should send a fix to the GTK+ folk, arranging that their
"automake"/"autoconf" macros set "CPPFLAGS", if it's possible to make
them do that.)
Hopefully, this won't cause Ethereal to fail to configure or build on
some wacky platform with some wacky set of libraries ("libpcap", "zlib",
SNMP, whatever) installed in some wacky directory. At this point, I've
become unconvinced that it's impossible to set up "autoconf"-based stuff
so that it cannot possibly trip over somebody's configuration that you
haven't bumped into yet, so the best you can do is try to fix problems
as they come up, and hope that the problem isn't inherently insoluble,
forcing you to choose *which* configuration has to change or not run
your package....
I'll try my checkin on Solaris 7/x86 and Debian 2.0/x86 here; it seems
to work on FreeBSD 3.3/x86.
