(grin) It kind of flakes out when I dump that many packets on the
program. I've tried it on a Sun Ultra2 with 2x166mhz CPU's, 512MB
RAM, and an hme interface, as well as a Sun Ultra ES/3500 with 6x400mhz
CPU's, and 3GB RAM. It seems remarkably compute efficient during the
packet acquisition stage, but the analysis stage seems to bomb out a
lot.
Regards,
Wes Brown
-----Original Message-----
From: Brown, Wes
Sent: Thursday, August 05, 1999 6:39 PM
To: 'Guy Harris'; Brown, Wes
Cc: 'ethereal-dev@xxxxxxxx'
Subject: RE: [ethereal-dev] Ethereal on Solaris -- lexical scanner
problems.
Sure enough, installing the GNU lexical stuff (bison, flex) solved
the problem. ( Needed to install those tools anyways ... )
Just fired it up. It works!
Now, let's trundle over to the network test lab, and see if it can
capture a sustained packet load of 17K/sec ... ;)
Wes
-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxx]
Sent: Thursday, August 05, 1999 6:15 PM
To: Brown, Wes
Cc: 'ethereal-dev@xxxxxxxx'
Subject: Re: [ethereal-dev] Ethereal on Solaris -- lexical scanner
problems.
> I'm attempting to compile Ethereal on my Solaris machine.
>
> Everything seems to go fine, until it gets to the linking stage.
>
> At that point, there's apparently a conflict between the two parsers
> generated by lex/flex in libpcap and dfilter-scanner.
>
> Any suggestions as to how to resolve this? I am using gcc, on a
> Solaris-2.5.1 machine -- and using the Solaris lexical compiler.
Alas, Solaris's "lex", like Solaris's "yacc", doesn't have a nice
command-line argument to tell it to prefix global symbols with something
such as "ethereal_" or "pcap_"; the "Makefile.in" for "libpcap" will use
those features, if present, for "flex" and "bison", if your system has
them.
Right now, the only workaround I can offer is to get them and use them
to build "libpcap"; that should, at least, give its symbols names
prefixed with "pcap_", which should keep those symbols out of the way of
Ethereal - and of any other programs that use "libpcap" and
"lex"-generated scanners and/or "yacc"-generated parsers.
(Well, another possibility would be to edit "dfilter-scanner.c" and
"dfilter-grammar.c" by hand to rename the symbols.)
Ethereal requires "flex" and either "bison" or Berkeley "yacc"; we
distribute the results of those programs with Ethereal, so you don't
need them to build Ethereal (unless you modify the scanner or grammar),
but we don't use the prefixing features with them, so our scanner and
parser don't have symbols prefixed with, say, "ethereal_".
It might also be nice to, if there isn't "flex" or "bison", have the
build process run a "sed" script or something such as that to generate
the resulting ".c" file, to do the symbol renaming.
