file, rather than the top-level Ethereal configuration file, check for
"inet_aton()", "inet_pton()", and "inet_ntop()". Then make its
Makefile.am include the appropriate object files if necessary.
Otherwise, they don't get built and put into libethereal, and therefore
attempts to link with anything in libethereal that uses them fail on
platforms that lack ethem, causing the build to fail.
That means a bunch of things need to be fixed to cope with libethereal
having its own "config.h" file; this means removing the include of
"config.h" from some libethereal header files. Move the definitions of
the path names used only by "resolv.c" to "resolv.c" from "resolv.h" (so
"resolv.h" doesn't need "config.h", define HAVE_PLUGINS in the configure
script (so we don't have to include it in "plugins.h" to check whether
HAVE_DLFCN_H is defined).
Unfortunately, stuff outside libethereal needs to know PLUGIN_DIR; for
now, define that in the top-level configuration file, and have Ethereal
and Tethereal pass it as an argument to "epan_init()" - that should be
cleaned up at some point.
Remove from the top-level configure script checks for things used only
in libethereal.
svn path=/trunk/; revision=2498
as far as I know, the only way to get IFF_UP, IFF_LOOPBACK, "struct
ifreq", and "struct ifconf" defined, and those are required in order to
get, via SIOCGIFCONF, the interface list, and to exclude interfaces that
aren't up and handle loopback interfaces differently from other
interfaces.
If we're on UNIX and have libpcap, we should do the same; that way, if
the system doesn't have <net/if.h> installed, the compile will fail with
an "I can't find <net/if.h>" error, rather than the configure indicating
that <net/if.h> can't be found, causing "util.c" not to include it,
causing it to fail with complaints about IFF_UP, IFF_LOOPBACK, and
various structures not being defined - the former tells you the root
cause, the latter doesn't.
svn path=/trunk/; revision=2442
a framework for the dissector; of the more than 400 NCP packet types, only
a handful are defined. But this dissector framework is much better than
the previous one.
svn path=/trunk/; revision=2173
a waste of time. Instead, set $(PERL) to @PERL_PATH@ in the Makefile and
call dfilter2pod.pl via $(PERL) $(src_dir)/dfilter2pod.pl
svn path=/trunk/; revision=2171
package build targets. Move ethereal.spec(.in) to packaging/rpm.
The spec file is different from Henri's. We might want to switch to his
for the sake of consistency.
svn path=/trunk/; revision=2162
is installed in packaging/solaris.stage, and from there the package
is created. The checkinstall script depends on GTK+/Glib residing
in /usr/local.
svn path=/trunk/; revision=2151
<arpa/inet.h>, but is, in some fashion, declared differently from the
way we declare it in "inet_v6defs.h", but "inet_ntop()" isn't defined,
so we include "inet_v6defs.h" in "inet_pton.c", which causes
"inet_pton.c" not to compile as we get a collision between the two
declarations.
Move the declaration of "inet_aton()" to "inet_aton.h", define
"NEED_INET_ATON_H" iff we didn't find "inet_aton()" in the system
libraries, and include "inet_aton.h" in the callers of "inet_aton()" iff
"NEED_INET_ATON_H" is defined, so that it doesn't get declared by us if
"inet_aton()" is defined by a system library (which hopefully means it's
declared in <arpa/inet.h> instead).
svn path=/trunk/; revision=2137
I'm going to go ahead and install the plugins in a "0.8.7" directory, and
continue incrementing the micro number until the minor version changes to 9.
Then for all of 0.9.x, the plugin directory will be "0.9" until the ABI
changes again. This should cause less confusion, even if it means the
plugins don't change between 0.8.6 and 0.8.7.
svn path=/trunk/; revision=1834
gives you everything that "-Aa" does, plus the extensions that you get
only with "-Ae", and that there's no need to specify "-Aa" if you've
specified "-Ae". Therefore, we get rid of "-Aa".
svn path=/trunk/; revision=1769
to add Axis ethernet vendor ID, use libtoolize in autogen.sh, and
provide the very dangerous option of installing ethereal setuid.
I've added a "DANGEROUS" comment to the description of the
--enable-setuid-install option which displays in "./configure --help".
Removed generated files tha old libltdl/.cvsignore brought to my
attention by Peter.
svn path=/trunk/; revision=1616
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
zlib problems, and my workaround appears to handle that problem, so
let's reenable zlib support in NetBSD and look into it in more detail if
there's still a problem.
svn path=/trunk/; revision=1494
linking with "-lsnmp".
Link only Ethereal and Tethereal with "-lpcap"; don't link editcap, or
any of the test programs that the configure script builds, with it
(because that means you also have to arrange that those test programs be
linked with @SOCKET_LIBS@ and @NSL_LIBS@) - i.e., don't add it to LIBS,
add it to PCAP_LIBS, and use that only for programs that need it.
svn path=/trunk/; revision=1484
make it link with them.
Provide dependencies for Tethereal as well.
Tethereal may need to be linked with "-lsocket" and/or "-lnsl"; check
for that, and arrange that it be linked with them if necessary.
svn path=/trunk/; revision=1483
with MSVC 6.0 and 'nmake', the make tool that comes with MSVC.
It compiles, links, and runs. It doesn't run correctly. There's a problem
when reading files. I'm getting short reads. I'm not linking in zlib or
libsnmp because it first needs to be debugged.
I changed the plugin code to use gmodule instead of libltdl, but the
Unix build still links ethereal against libltdl. I'll fix that tonight; sorry
about leaving it in such a sad state, but I wanted to check in this code
before I left work on a Friday night. Ethereal still works, but the
building is less than optimal.
svn path=/trunk/; revision=1479
Added lots of #ifdef HAVE_*_H wrappers.
Added some #defines in config.h.win32
Check for more headers in configure.in
Added prototype for inet_aton() in inet_v6defs.h.
Changed "BYTE" token (i.e., #define) in ascend-gramamr.y because it
conflicts with a windows definition. Use HEXBYTE instead.
svn path=/trunk/; revision=1448
by default.
Use the automake mechanisms for it, and, having done so, arrange that it
not be linked with GTK+ (which it doesn't need) - it currently links
with libpcap, but that should be fixed as well. (It also needs a man
page.)
svn path=/trunk/; revision=1445
Make the default plugindir $(libdir)/ethereal/plugins/0.8. Ethereal now
looks for plugins in the following directories:
/usr/lib/ethereal/plugins/0.8
/usr/local/lib/ethereal/plugins/0.8
$plugindir (if different from above)
$HOME/.ethereal/plugins
svn path=/trunk/; revision=1382
there are no SNMP libraries to use in a real dissector; this means that
other dissectors don't have to care if there are SNMP libraries, they
can just call "dissect_snmp()" - and this also simplifies "Makefile.am"
and "configure.in" a bit, as they just treat "packet-snmp.c" and
"packet-snmp.h" the same way they treat other dissector source files.
svn path=/trunk/; revision=1214
by pre-2.13 "autoconf", and there may be other problems with pre-2.12
"autoconf" as well; require "autoconf" 2.13 or later.
svn path=/trunk/; revision=1187
Gilbert Ramirez