libpcap than in tcpdump.org libpcap; it's been deprecated for that
reason. "pcap_open_dead()" has been in libpcap since 0.6, so only for
0.5[.x] will you have "pcap_compile_nopcap()" but not "pcap_open_dead()"
- for now, we use "pcap_open_dead()" rather than
"pcap_compile_nopcap()", and don't do the check for capture filters in
systems with libpcaps that lack "pcap_open_dead()".
svn path=/trunk/; revision=9341
The PCRE test in acinclude.m4 and epan/acinclude.m4 don't work
if PCRE exists in a non-system directory. The problem is that
LDFLAGS and LIBS are set incorrectly. LIBS shouldn't contain -L
arguments.
svn path=/trunk/; revision=9309
New "matches" operater in display filter language. Uses PCRE.
If a "matches" operator is found in a dfilter
while libpcre has not been used to build the binary, then an
exception is thrown after using dfilter_fail() to set an apporporiate
error message.
svn path=/trunk/; revision=9182
1. the --without-adns case wasn't handled correctly;
2. the reporting at the end of the configure didn't deal with
the case were the configure check failed (as in my example,
where I only had the libadns package installed, not
libadns-devel) - it reported that ADNS would be used.
svn path=/trunk/; revision=8663
-L/usr/kerberos/lib -ldes425 ...
This works on Linux (RH 9.0) but I am not sure about Solaris. Solaris is
such a difficult environment to work with compared to Linux or FreeBSD.
svn path=/trunk/; revision=8325
Support can be enabled at configure time by using "--with-adns=DIR".
If support is enabled, async queries happen whenever host name resolution
is enabled. Do we need a separate preference for async queries?
Currently, only IPv4 reverse queries are supported. I can add IPv4 forward
lookup support, but I don't have any way to test IPv6 queries.
svn path=/trunk/; revision=7640
include <ucd-snmp/snmp.h>, we incldue <ucd-snmp/ucd-snmp-config.h>, and,
at least with some UCD SNMP versions, you can't just include
<ucd-snmp/snmp.h> without including a header to typedef "oid", so you
get a warning from the configure script if it's built with autoconf 2.57
(it whines because the test program won't compile but the header exists).
svn path=/trunk/; revision=7220
Get rid of acconfig.h, as it's an archaism; put descriptions
into AC_DEFINE instead. That squelches some warnings from
later versions of autoconf.
Fix an unquoted call to AC_MSG_ERROR.
Move the stuff to define HAVE_SOME_SNMP into configure.in.
svn path=/trunk/; revision=7203
shouldn't require it to exist. Instead, as we're already checking
whether we can find <pcap.h> (which is the only thing we actually
include - we rely on it to include whatever BPF headers are necessary),
we print the big "are you sure you installed the development package?"
message if we don't find "pcap.h".
svn path=/trunk/; revision=7120
"pcap.h", in case $prefix is set to "/usr/include" or
"/usr/local/include" on a system with the Red Hat "feature" of burying
pcap.h in a "pcap" subdirectory.
svn path=/trunk/; revision=7007
- remove nested functions
- use char *pcap_version instead of char pcap_version[]
Changed the fix for the nested functions to use the mechanisms provided
by autoconf.
svn path=/trunk/; revision=6963
Don't add "-I/usr/include" to CFLAGS or CPPFLAGS; GCC 3.1 warns
about it, and it's not necessary.
Expand the plugin directory path used for installation at
installation time, rather than configuration time, so the user
can reset "prefix" at installation time.
svn path=/trunk/; revision=5828
Make the directory option to "--with-ucdsnmp" optional. Handle
"--with-ucdsnmp" similar to the way "--with-pcap" is handled.
Get rid of unnecessary #defines in "packet-cops.c".
Get rid of no-longer-necessary include of "dlfcn.h" in "packet-snmp.c".
svn path=/trunk/; revision=4930
even if it doesn't have "gzgets()", so one might think we could use it
by using our own replacement for "gzgets()".
One would be wrong to think so, however, as the "gzseek()" it has
doesn't actually work when reading uncompressed files.
zlib 1.0.9 has "gzgets()", and fixes that bug, so we rever to checking
for "gzgets()" rather than "gzseek()", so that we don't accept pre-1.0.9
versions of zlib, and we get rid of our "gzgets()" replacement.
svn path=/trunk/; revision=4702
check for GNU "sed", and skip the "bad sed" checks if it's
found;
check for "/bin/sed" as well as "/usr/bin/sed" on Solaris;
put the "sed" checks into a separate section of code with its
own test for the host OS, to make it a bit cleaner to add any
checks needed on other OSes.
svn path=/trunk/; revision=4681
"--define", we now build the RPM and SRPM packages in packages/rpm.
As a result, one need not be root to build RPM-based packages.
Move the specfile to packaging/rpm/SPECS.
Update the INSTALL document to include the various packaging makefile
targets.
svn path=/trunk/; revision=4581
(well, the check used to be a check for gzgets(), but we now have our
own version of that), so that, on a system with multiple versions of
zlib where the GTK+ -L flags get you an old version without gzgets(),
the configure fails, rather than the build failing.
svn path=/trunk/; revision=4566
don't need to check whether zlib has them. We *do*, however, have to
check for "gzseek()", as we don't have our own version of that.
svn path=/trunk/; revision=3963
versions of these commands in file_wrappers.c. This allows us to
compile successfully even on platforms where X has an older zlib built
in.
Removed this restriction from acinclude.m4
svn path=/trunk/; revision=3948
checking for "gzgets()" in zlib.
If there is a "zlib.h" header, and there is a "gzgets()" in zlib, check
whether we find "gzgets()" in zlib when we link with the GTK+ link
flags, and, if not, fail. People often grab XFree86 source and build
and install it on their systems, and they appear sometimes to
misconfigure XFree86 so that, even on systems with zlib, it assumes
there is no zlib, so the XFree86 build process builds and installs its
own "mini-zlib" in the X11 library directory. The "mini-zlib" lacks
"gzgets()", and that's the zlib with which Ethereal gets linked, so the
build of Ethereal fails.
svn path=/trunk/; revision=3849
"--with-pcap", it adds the "include" subdirectory of that directory to
the list of directories to search for include files, rather than adding
the directory itself.
Check whether libpcap defines "pcap_version", and define
HAVE_PCAP_VERSION if it does. Use "pcap_version" iff HAVE_PCAP_VERSION
is defined, rather than special-casing MacOS X.
Don't #define a string for the WinPcap version; just leave
HAVE_PCAP_VERSION undefined on Windows, as WinPcap 2.2beta is out, so we
can no longer assume that the Windows version of Ethereal is using
WinPcap 2.1.
svn path=/trunk/; revision=3792
specified to "--with-pcap", add that directory to the include file and
library search paths, so that you can use "--with-pcap=DIR" to search
for libpcap in a directory other than the standard ones (either because
it was installed somewhere other than under "/usr" or "/usr/local", or
because you want to use a special version you've installed rather than
the standard one).
svn path=/trunk/; revision=3611
(without those updates, I'm not even certain it was doing the right
thing even with autoconf 2.13, as it was sticking "dnl" into the program
it was handing to the C preprocessor, although, as it was only handing
it to the preprocessor, the extra "dnl" may have been harmless).
svn path=/trunk/; revision=3409
AC_MSG_RESULT is an error (it produces a message without a newline at
the end, as AC_MSG_RESULT is supposed to finish the message with the
result of the test), and, according to the autoconf documentation,
you're not supposed to use AC_MSG_RESULT without AC_MSG_CHECKING,
either.
svn path=/trunk/; revision=3332
searching that tries to figure out in what directory libpcap lives - we
should treat "-L" just like "-I", rather than adding a ton of
complication to do it the way the autoconf maintainers think, for some
reason, it should be done (by adding "-L" flags to LIBS - "-L" flags
don't specify libraries, so I have no clue why they think they belong in
LIBS; they specify a search path for libraries, just as "-I" flags
specify a search path for header files, so they strike me as "flags to
the linker" rather than "libraries", and LDFLAGS, unlike LIBS, appears
before *all* "-l" flags, including those specified by PCAP_LIBS and so
on).
svn path=/trunk/; revision=1516
Guy Harris