Hi Jeff,
I've also noticed that with a modern x86-64-based machine (with 3GB of RAM, and a triple-core AMD Phenom II CPU), and a recent-ish version of GCC running under *buntu. It certainly seems like a good stress test for any compiler/OS/machine combination.
With that in mind, just what is packet-parlay.c being used for, anyway? (And why is it so large?)
Apologies in advance for the stupid questions,
Tyson.
2012/6/5 Jeff Morriss
<jeff.morriss.ws@xxxxxxxxx>
Jeff Morriss wrote:
Anders Broman wrote:
Hi,
It should be possible to make the giop plugins built in dissectors now, is that something we'd want to do?
I'd be all for it mainly so/if we can put packet-parlay.c at the top of the list of dissectors so that my "make -j X" can start the 15 minutes it takes to compile that beast as early as possible! (Okay, 15 minutes is probably an exaggeration, but it does take a *very* long time to compile.)
epan/dissectors/packet-parlay.c:96834:17: note: variable tracking size limit
> exceeded with -fvar-tracking-assignments, retrying without
I wonder if modern GCCs will have that problem or if it's just this version or (doubtful) the architecture. It would be really nice if this file could be split up.
--
Fight Internet Censorship!
http://www.eff.orghttp://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844
